Klassennamen: Naja, die Teile sollten nach den Objekten benannt werden, die sie modellieren: Person, JsonWrapper, GameArea, …
Methoden:

• bei Subs/void methods Imperativbezeichnungen, bei denen klar wird, was sie Sub macht: CalculateFreeMemorySpace, SendEmailTo, WashMyCar
  
• bei Functions/non-void methods (tw. Imperativ-)Bezeichnungen, bei denen klar wird, was die Methode zurückgibt: IsValid, GetCountOfActiveUsers, GetValidIdFromUserInput
  
• bei Propertys/Feldern/Variablen: was in ihnen drinsteckt, also nicht der Typ, sondern die Bedeutung: CountOfUnreadMails, BackgroundColor, PhoneNumber, DateOfBirth
  

Kommentare/Doku: Ich versuch meine Programme so zu standardardisieren (innerhalb meiner eigenen Programme!), dass ein User bei einem neuen Programm durch wiederkehrende und -erkennbare Designs oder eindeutige Beschriftungen keine sonstige Doku braucht. Das geht aber v.a. deshalb, weil ich mit den Usern täglich zusammenarbeite und selber User bin. Da zeigt sich schnell, wo bei Beschriftungen und Benutzerführung nachgebessert werden muss. Bei Code: Ich glaub ich habe in meinen zig (Mini)Apps nur eine Stelle, die ich selber kommentieren musste, weil da irgendwas komisches beim Ablauf war, was ich weder besser erklären noch anders in Code ausdrücken konnte und mich daher gezwungen sah, mein zukünftiges Ich davon abzuhalten, unbedacht den Code zu "optimieren", indem ich eine Erklärung schrieb. Obwohl, ich korrigiere: einige meiner DLL-Methode haben diese XML-Kommentierung. Aber eigentlich auch nur, weil ich damals damit mal experimentiert hatte.

Schliesse mich meinem Vorredner an.
Aber da gibts auch von MS dolle Richtlinien für, was Benamung und Kommentation angeht.
Stark überwiegend stimme ich mit dem überein, aber in einigen Punkte hätte ich Kritik:

• Etwa ein durchdachtes Prefix-System erlebe ich als sehr nützlich
  
• Und MS kommentiert viel zuviel - wie gesagt: guter Code kommentiert sich durch gute Benamung. Zusätzliche Kommentation ist redundant, und Redundanzen sind Gift - immer.
  Das gilt auch für Doku-Kommentare.
  

Ausserdem gestalte ich meine Codes immer möglichst kurz. Das bedeutet zB, dass ich auch keine unsinnigen Leerzeilen dulde.
Auch eine Leerzeile trifft eine Aussage, fördert oder behindert die Lesbarkeit.
Es kommt darauf an, Einheiten zu schaffen, die inhaltlich zusammengehöriges denn auch zusammenfassen.
Und so eine Einheit möchte möglichst komplett im Blick haben - das befördert das Verständnis ungemein.

Du kannst dir übrigens inne Tipps&Tricks haufenweise BeispielCodes runterladen, und so bischen Einblick erhalten in verschiedene "Stile".

ErfinderDesRades schrieb:

Aber da gibts auch von MS dolle Richtlinien für, was Benamung und Kommentation angeht.

docs.microsoft.com/en-us/dotne…delines/naming-guidelines

ErfinderDesRades schrieb:

guter Code kommentiert sich durch gute Benamung. Zusätzliche Kommentation ist redundant

100% Zustimmung.
Kommentare gehören nur dahin, wo der Code etwas nicht Offensichtliches ausführt.

@iSteffen Suffixe wie zu C / C++-Zeiten sind out, zumal Dir die IDE anzeigt, was an Information verfügbar ist (=> XML-Kommentare).
@petaod Weißt Du in einem halben Jahr, was damals offensichtlich war?
Ich neige inzwischen zu einer intensiven Kommentierung.
Variablen, Properties und Prozeduren bekommen den XML-Kommentar, der wird dann bei HOver angezeigt.
Insbesondere bei komplexen (Geräte-)Abläufen und komplizierten Berechnungen muss nicht nur die Formel erkennbar sein,
es gehört auch hin, wo die Formel her kommt und ggf. was mir bei der Implementierung durch den Kopf gegangen ist.
Das hab ich meinem Chef schon beigebracht.

RodFromGermany schrieb:

Weißt Du in einem halben Jahr, was damals offensichtlich war?

Ich schon.
Ich hatte kürzlich ein 10 Jahre altes Projekt in der Hand und keine Verständnisschwierigkeiten.
Es heißt ja nicht, dass ich gar keine Kommentare schreibe, sondern nur relevante.

Etwas anders ist es, wenn andere mit meinem Code weiterarbeiten müssen.
Da gibt's dann etwas mehr "überflüssige" Kommentar.
Es kommt halt arg auf die Skills des Nachfolgers an.
Da sind auch welche dabei, die mit und ohne Kommentar Verständnisprobleme haben.
Meistens gebe ich für diese dann ein paar Stunden Übernahmeschulung.