Wie und wieviel kommentiert Ihr Euren Code

[striderx]

Von der IT eines großen Konzerns kenne ich Programmiervorgaben, die einen bestimmten Anteil von Kommentierungen einfordern (z. B. 20 Prozent des Quellcodes).

Der Hintergrund dafür: Geschäftskritische Anwendungen müssen auch wartbar sein, nachdem die ursprünglichen Entwickler nicht mehr zur Berfügung stehen. Des weiterem wird in diesem Bereich ja auch tailoristisch gestückelt und/oder nach draußen Vergeben - da ist es unabdingbar, dass mit vertretbarem Aufwand nachvollziehen kann, was in dem jeweiligen Segment los ist. Und ich bezweifele, dass man bei komplexen Anwendungen Sourcecode immer so schreiben kann, dass er leicht nachvollziehbar ist.

Anders sieht es natürlich aus, wenn man Einzelkämpfer ist. Dann kann man sich auch mit Nachrichten an sich selbst begnügen (siehe Post von Frank).

Und noch ein Gedanke: Nach meiner Erfahrung kann die Formulierung eines Kommentars durchaus noch einmal eine Art der Qualitätssicherung sein.

[jaenicke]

Zitat von striderx:

Von der IT eines großen Konzerns kenne ich Programmiervorgaben, die einen bestimmten Anteil von Kommentierungen einfordern (z. B. 20 Prozent des Quellcodes).

Der Hintergrund dafür: Geschäftskritische Anwendungen müssen auch wartbar sein, nachdem die ursprünglichen Entwickler nicht mehr zur Berfügung stehen.

Dafür sind solche Vorgaben oft genau nicht geeignet. Ich habe schon solche Projekte gesehen. Da wurde dann um die Quote zu erfüllen extra kommentiert, dass eine Schleife für jeden Eintrag einmal durchlaufen wird usw., dafür wurden Variablennamen oft nur mit einem Zeichen geschrieben. Denn die Erklärung steht ja im Kommentar.
Das macht den Quelltext dann deutlich schlechter lesbar und extrem schlecht zu warten.

Deshalb stammen solche Vorgaben oft aus dem Management und nicht von denjenigen, die damit arbeiten. Um es mal vorsichtig auszudrücken.

Viel wichtiger als Kommentare oder Dokumentationen der einzelnen Routinen ist erst einmal eine Gesamtdokumentation, in der drin steht wie das ganze Projekt organisiert ist, wie die Abläufe grundsätzlich sind (Pattern, Dateiorganisation, ...), usw.

Denn wenn der Quelltext sauber geschrieben wurde, lese ich den Code eher schneller als jede Dokumentation. Wenn ich aber keinen Grundfahrplan habe wie das Projekt aufgebaut ist, finde ich mich erst einmal schlecht in das Projekt hinein. Und das kostet dann wirklich sehr viel Zeit.

Zitat von himitsu:

Die guteren CVS sagen dir aber wer welche Zeile zuletzt eingecheckt hat.
Bei SVN nennt sich das Blame (Schuld).

Und man kann dann auch von dort aus die vorherige Änderung der Zeile suchen usw., egal ob bei Git, Mercurial, SVN, ...

[hoika]

Hallo,
ich hatte ja gesagt, dass die auskommentierten Änderungen auch mal gelöscht werden.
Das mit dem Blame habe ich so nicht verstanden ...
Wir haben SVN, mal im RedBook lesen.

Trotzdem möchte ich durch Lesen des Quellcodes sofort wissen, wann wer für welche Version das eingebaut hat.
Und Version muss nicht mit der SVN-Branch ocer SVN-Tag übereinstimmen.

Aber das soll jeder ja so machen, wie er es gewohnt, versteht oder es gefordert wird.

http://svnbook.red-bean.com/de/1.7/s...n.c.blame.html
Nun ja, so gut ist das dann doch nicht (Stichwort Leerzeichen korrigiert).
Aber für sowas haben wir ja eh keine Zeit

[Rollo62]

Zitat:

ch hatte ja gesagt, dass die auskommentierten Änderungen auch mal gelöscht werden.

+1

Das finde ich während der Entwicklung, in dem jede Menge Tests gemacht werden völlig OK.
Gelöschte Tests wiederherzustellen ist viel problematischer als sie einfach wegzukommentieren.

Guter Stil hin, schlechter Stil her: Ich mache das was mich schneller zum Ziel bringt, auch wenn's nicht immer hübsch aussieht

Rollo

[striderx]

"Real programmers don’t document. If it was hard to write, it should be hard to understand."

"Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing."


Wie viele schöne andere Sprüche zu finden auf

https://henrikwarne.com/2016/04/17/m...amming-quotes/