Schau dir mal des hier an: Naming Guidelines und C# Coding Conventions

@Drahuverar Kommentare machst Du in den Klassen so:

Drahuverar schrieb:

'Manch einer kommentiert so...
Dim sTest1 As String = ""
Dim sTest2 As String = "" 'Manch einer kommentiert so...

Es gibt Inline-Kommentare, es gibt Block-Kommentare und es gibt globale Kommentar-Blöcke (siehe Vorpost).
Und alle haben ihre Berechtigung, je nach dem worauf sich der Kommentar bezieht.

Drahuverar schrieb:

zu der Benamung meiner Variablen..

gibt's Style-Guides: msdn.microsoft.com/en-us/libra…o/ms229002(v=vs.100).aspx

Drahuverar schrieb:

englische oder deutsche Namen

Letztendlich kommt es auf die Vorgaben an.
In internationalen Projektumgebungen wirst du zu englisch verdammt sein.
Besonders früher war es aber auch bei deutschen Behörden-Projekten üblich, deutsche Nomenklatur als Pflicht vorzugeben.
Wenn nichts vorgegeben wird: Englisch, das passt sich am besten der Programmiersprache an und macht das Programm lesbarer.

Wenn du jedoch die Wirklichkeit von deutschen Fachbegriffen in deiner Klasse abbilden musst, sollte man die nicht zwingend ver-englischen.
Immer so agieren, wie es das Programm am besten lesbar macht.

Drahuverar schrieb:

Was macht ihr wenn ihr einen X-Langen Code in einer Sub habt?

Ein Redesign

Wenn ich schon damit anfange erklärende Kommentare für Funktionen und Klassen zu schreiben, dann gleich mit XML-Kommentaren:

Rufst du dann diese Funktion auf, wird dir dein Kommentar im intelliSense angezeigt innerhalb von Funktionen sollte es nur seltens Kommentare benötigen.

Das equivalent für VB.NET sollte mit ''' funktionieren

[OT]Bei den XML-Kommentaren ist übrigens GhostDoc sehr hilfreich.[/OT]
Bei der Variablenbenennung verzichte ich grundsätzlich auf Präfixe bzgl. des Typs der Variable. Ich achte eher darauf, dass sie einen aussagekräftigen Namen - oder, bei der 1:1-Implementierung einer Formel in einer eigenen Methode, die Variablen Bezeichnung zu verwenden.

ein paar nützliche Hinweise - insbes. was Kommentation und Benamung angeht - fand ich neulich hier: Lesbaren Quelltext schreiben

Generell code ich englisch, nur bei Datenbänkerei bekommt man mit elend vielen Entitäten und Attributen zu tun - da halte ich die Englisch-Linie nicht durch.
Weiters versuche ich überall mich möglichst kurz zu fassen. Das betrifft Formulierungen, aber geht bis hin zu meinen Benamungs-Gewohnheiten.

Welcher Benamungs-Gewohnheit man anhängt ist vergleichsweise schnuppe (daher die ganzen Glaubenskriege darum ) - aber man sollte sie konsequent einhalten.
Und in einem weiteren sind sich alle Benamungs-Glaubens-Krieger glaub einig: sprechend benamen - Nomen est Omen!

ErfinderDesRades schrieb:

welcher Benamungs-Gewohnheit man anhängt ist vergleichsweise schnuppe

oder man orientiert sich etwas an der Microsoft Konvention

>>msdn.microsoft.com/de-de/library/ms229045(VS80).aspx

aber wie bereits erwähnt jedem das seine...

Drahuverar schrieb:

VB.NET-Quellcode

1. Dim bExists as Boolean = False
2. Dim iCount as Integer = 0
3. Dim sText as String = ""

hier trifft zu, dass Prefixe sinnlos sind, nämlich weil die Namen bereits sprechen
Da das aber jeder selbst weiß, was da kommentiert ist, kommen die Kommentare natürlich weg

So sieht kurzer, eindeutiger, lesbarer Code aus.

Das ist nun aber schon so trivial, dasses sogar als Einzeiler gut lesbar ist:

ErfinderDesRades schrieb:

VB.NET-Quellcode

1. Dim exists = False, counter = 0, txt = ""

führt bei mir zu Brechreiz.

Aber verstehen tust du die Zeile dennoch problemlos, oder?

ErfinderDesRades schrieb:

verstehen

keine Frage, nur meinem Ordnungssinn gefällt dieses Merge nicht.

ErfinderDesRades schrieb:

Dim counter = 0

sieht doch so schon ganz gut aus ,
jedoch bin ich persönlich der Meinung die Deklaration des Datentyp sollte noch hinzugefügt werden damit es eindeutig und klar ist. Ein counter könnte ja z.B. auch vom Typ Long sein und nicht Integer ...

ist auch nur ein Beispiel, ziemlich irrelevant für die Praxis.
Weil meist kann und sollte man die Deklarationen ja da positionieren, wo die Variablen erstmalig gebraucht werden.
Also sone Kopfzeile in einer Methode, wo erstmal alle möglichen Variablen definiert werden, das ist ja eher vb6.

@MrNobody - Geschmacksache. Ich bevorzuge die Typ-Inference ihren Job machen zu lassen, und wenns wirklich mal ein Long-counter sein soll, krieg ich das noch immer hin:Explizites Hinschreiben der Datentypen ist auch nur ein Bedienen von Redundanzen - der Compiler braucht das nicht.
Manche Refactorierung ist auch einfacher, wenn man die Datentypen voneinander ableiten lässt:Da hab ich den Datentyp aller 3 Variablen geändert, wenn ich nur in zeile#1 ein L anhänge.

MrNobody schrieb:

eindeutig und klar

Machst Du Option Infer Off.

Drahuverar schrieb:

Bekommst du dafür Zeit freigestellt, oder wird das von Anfang an mit einkalkuliert?

Wenn das mein eigener Code ist, wird das schon gar nicht passieren.

Und wenn es Fremdcode ist, gibt es zwei Varianten:
1) Ich muss nur Minimaländerungen machen, dann mache ich nur diese und lasse alles andere wie es ist.
2) Sobald es größere Änderungen sind, ist bei einem unübersichtlichen Programm ein Redesign meist schneller als sich in die verwirrten Strukturen des Originalprogrammierers einzuarbeiten.
Zumal solche Spaghetti-Codes meist auch noch recht fehlerbehaftet sind.
Es muss ja nicht gleich das komplette Projekt neu geschrieben werden.
Aber die Module, die ich entscheidend anfasse, müssen hinterher sowohl von mir als auch von anderen wartbar sein.


Es gibt bei mir nicht die Frage, ob ich für etwas Zeit freigestellt bekomme.
Entweder ich nehme die Aufgabe / den Auftrag an und dann benötigt es die Zeit, die ich brauche, bis es zufriedenstellend läuft (natürlich gebe ich bei komplexen Projekten eine Aufwandschätzung dafür ab).
Oder ich kriege die Zeit nicht, dann soll das Zeug machen, wer will.

Drahuverar schrieb:

ErfinderDesRades schrieb:

Dim exists = False, counter = 0, txt = ""

Führt das nicht dazu das die Variablen zur laufzeit randomized sind?

Nein, bestimmt nicht.
Der Einzeiler ist für den Compiler 100% identisch mit dem DreiZeiler

Ich weiß auch garnet (sicher), was du unter laufzeit randomized Variablen verstehst, und wieso solch beim Einzeiler dann auftreten sollte, beim 3-zeiler nicht.

Mach doch einfach paar Experimente damit.

Drahuverar schrieb:

Dim sTest1, sTest2, sTest3, sTest4 As String

Verhält sich unterschiedlich in verschiedenen VB-Dialekten.
In VBA wäre nur sTest 4 ein String, der Rest vom Typ Variant.
In VB.net wäre alles vom Typ String.