spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Für wen sind denn die Kommentar bzw. der Quelltext bestimmt?

Warum Kommentare für die Community englisch sein sollen ist mir auch nicht klar. Das kommt ja auch die Community an. Man sollte es wie mit der Variabelbenennung halten. Wenn du allein arbeitest, mach es so wie du es selbst am besten verstehst. Wenn du zwischendurch Wörter nachschlagen musst bist du dir hinterher möglicherweise nicht mehr sicher was du sagen wolltest. Wenn du gut mit Deutsch klar kommst, spricht ja eigentlich nichts dagegen. Klar sieht es nicht cool aus wenn Klasse deutsche Namen haben oder der Code eher deutsch gehalten ist, aber wenn der Entwickler es so besser und schneller verstehen kann, ist alles gut. Sobald mehrere Leute mit am Projekt arbeiten muss/sollte man sich zusammen überlegen wie man das Problem angeht. Solange alle Deutsch sind, spricht für mich nie was dagegen sowas auf Deutsch zu schreiben. Sobald auch nicht Deutsche daran beteiligt sind macht englisch dann schnell mehr Sinn.
Ich geh aber davon aus dass du nur für dich entwickelst und auch allein entwickelst, und von daher mach es so wie es dir leichter fällt.

Zitat

Man sollte es wie mit der Variabelbenennung halten. [...] Klar sieht es nicht cool aus wenn Klasse deutsche Namen haben oder der Code eher deutsch gehalten ist

Ich würde sagen das ist nicht der Punkt, weshalb man zumindest Code in Englisch schreibt.
Der Unterschied vom Code zum Kommentar ist einfach, dass du Kommentare später übersetzen kannst, wenn es erforderlich sein sollte.
Mit dem Code geht es nicht so einfach, denn auf den wird von anderswo zugegriffen oder es gibt sogar eine Dokumentation die man von Grund auf überarbeiten müsste.

Außerdem finde ich es generell ätzend, wenn Englisch und Deutsch zusammengewürfelt wird.
Dann kommt gerne sowas raus:
object Ergebnis = (object)(this.Objekte).ZurückInvoke();
return (IResult)Ergebnis;

Ich schreibe meinen Code immer 100% englisch. Und nur wenn es unbedingt notwendig ist, die Kommentare ebenso.
Den Code verstehe ich auch so sehr gut. (Es kommt auch zu 95% nur Programmiersprachenvokabular vor)

Zitat

Ach ja, man muss nicht alles kommentieren ;-)

Das ist in der Regel eher nicht das Problem, denke ich.
Ich habe bei mir noch so ein paar Programmierjuwelen rumliegen mit mehreren zehntausend Zeilen Code, aber mit nur wenigen dutzend Kommentarzeilen.
(Wobei es sich bei diese Kommentarzeilen um auskommentierten Code handelt...)

Ich schreibe den Code komplett auf Englisch, dann gibts auch keine Probleme mit Umlauten usw.
Da mein Englisch zwar ausreicht um Fachbücher zu verstehen und (meistens) um aussagekräftige Bezeichner zu finden, aber nicht um komplexe Zusammenhänge zu erklären kommentiere ich auf deutsch. Sollte eine Übersetzung mal nötig sein werde ich wohl übersetzen (lassen) müssen.

Code-Kommentare (nicht zu verwechseln mit API-Doku) sind Deodorant für schlechten Code. Guter Code ist selbst-beschreibend und bedarf keiner Kommentare. Wenn es welcher bedarf, ist das ein Zeichen dafür, dass der Code müffelt - dann ist er zu lang, zu komplex, zu schlecht gekapselt oder die Variablen/Methoden schlecht benannt.
API-Dokumentation oder Kommentare an wirklich notwendigen Stellen (in der Tat ist eben nicht jeder Algorithmus sofort ersichtlich, auch wenn er nur 5 Zeilen lang ist, ist seine Notwendigkeit aus dem Kontext heraus manchmal eben nicht ersichtlich) sollte man in der Sprache schreiben, die man selbst mindestens "gut" kann und die die maximale Anzahl an Lesern des Codes umfasst. Im Beruf wird dies meist deutsch oder englisch sein. Privat wohl eher deutsch. Ich persönlich schreibe immer alles in englisch, weil ich es fließend spreche und schreibe.

Zitat

Guter Code ist selbstbeschreibend und bedarf keiner Kommentare.

Prinzipiell ist das schon richtig.
Aber dieses betonte "keiner" will ich mal überhört haben.

Mit Kommentaren kann der Code gegliedert werden.
Oder wenn ich zb- eine rückläufige Schleife einbaue. Ich werde in einen Jahr sicher nicht mehr wissen weshalb.
Zb. Bitoperationen können auch ohne gute Kommentierung auch ganz schrecklich undurchsichtig sein.

Der Kommentar was angesichts meines zweiten Absatzes wohl überflüssig, nicht?
Dennoch klingt eine "rückläufige Schleife" sehr trivial. Wenn ihr innerer Code zu lang ist, dann ist da auch mit Kommentar nur Deodorant am Werk, eine Korrektur wäre eine Aufteilung in weitere Funktionen/Methoden. Wie war die Daumenregel noch? Eine Methode mit mehr als 10 Zeilen ist zu lang? Auch ich halte mich da wohl eher selten dran, aber wenn man z.B. Sonar-Analysen machen lässt und Regeln (z.B. zyklomatische Komplexität maximal 10, maximal 25 Zeilen, anonyme Klassen und Lambda-Expressions maximal 20 Zeilen) dazu einpflegt, wie wir das auf der Arbeit machen, dann stellt man schon fest, dass kurze Methoden irgendwie sehr schön wartbar und übersichtlich sind. Nachteil ist die plötzlich explodierende Anzahl Methoden einer Klasse. Da heißt es dann eigenständige Funktionalitäten besser kapseln.

Bitoperationen ... ich weiß nicht, ob da mit Kommentar noch was zu retten ist. Ich denke da z.B. an Verschlüsselungs-Runden mit Shifts, Rotationen und XOR-Operationen. Da wird auch mit Kommentar nichts mehr besser, die Operation ist halt im Kern komplex. Beziehungsweise die Idee hinter der eigentlich ja simplen Operation.

Als Daumenregel würde ich es trotz all dieser Ausnahmen genau so stehen lassen: "Guter Code ist selbstbeschreibend und bedarf keiner Kommentare."
Baut man in den Satz Ausnahmen ein, dann ist bald alles nur noch eine einzige Ausnahme. Lieber nicht...