[Gelöscht] Guter Rat: Skripte verwenden nur im Ausnahmefall!!!

[chka]

glaubt mir selbst in großen firmen hat jeder Programmierer einen andere Handschrift, wenn da nix kommentiert ist versteht es auch nicht jeder sofort.

[Matsch]

glaubt mir selbst in großen firmen hat jeder Programmierer einen andere Handschrift, wenn da nix kommentiert ist versteht es auch nicht jeder sofort.

Na, wenn die Firma nach ISO 9000 zertifiziert ist, MUSS ausführlich kommentiert und dokumentiert sein. Alles andere würde dagegen verstoßen.
Aber das ist OT.

[jp112sdl]

Na, wenn die Firma nach ISO 9000 zertifiziert ist, MUSS ausführlich kommentiert und dokumentiert sein. Alles andere würde dagegen verstoßen.

Kenne mich mit den ISOs nicht so aus... du meinst aber direkt die 9000, oder auch die 9001?
Mal aus den eQ-3 Pressemitteilungen zitiert:

...und den Zertifizierungen ISO 14001 und ISO 9001 für das Umwelt- und Qualitätsmanagement überzeugt

[ayngush]

Es besteht ein Unterschied zwischen "Dokumentation" (gerne auch gemäß ISO 9001 wobei das eher Nebenschauplatz ist, interessanter ist da eher die ISO 27001) und der Kommentierung von Quelltexten.

Kommentare in Quellcode verstoßen meistens gegen das "Clean Code" Gebot, sind dadurch "anti pattern" und sollten vermieden werden.

Code: Alles auswählen

Comments rules:
   *  Always try to explain yourself in code.
   *  Don't be redundant.
   *  Don't add obvious noise.
   *  Don't use closing brace comments.
   *  Don't comment out code. Just remove.
   *  Use as explanation of intent.
   *  Use as clarification of code.
   *  Use as warning of consequences.

Und ja, "Clean Code" von Robert C. Martin ist das Standardwerk für Programmierung.

Wenn der Code also so komplex und undurchsichtig ist, dass man (Fachkraft) ihn auf dem ersten Blick nicht allein durch das anschauen des Codes versteht und es nur durch zusätzliche Kommentare im Quelltext möglich ist den Code nachzuvollziehen, dann ist der Code schlecht und sollte dringend überarbeitet anstatt durchkommentiert zu werden.

Und das in großen Firmen so viel undurchsichtiger Code-WirrWarr existiert ist eher dem "Legacy" und schlechter Organisation geschuldet.
Früher(tm) durfte quasi jeder Quellcode erzeugen, der mal ein halbes Semester Mathematik studiert und privat einen C64 hatte. Und das sind dann teilweise heutzutage die "Senior Software Developer" mit Projektverantwortung und und und... oder längst "verdaut und ausgeschieden".

Das macht sie aber nicht automatisch zu guten Entwicklern. Will damit sagen: Nur weil eine Firma groß ist, muss das nicht automatisch der Goldstandard für Quality of Code und Organisationsstrukturen sein. Eher im Gegenteil...

Edit: Und um das Rätsel aufzulösen, was dann Dokumentationen sind: Sämtliche Projektartefakte sind Dokumentationen, BPMN Diagramme, sämtliche UML-Diagramme, EPC/EPK, Handbücher, Whitepapers, Testprotokolle, Beschreibungen der Testszenarien, Schnittstellenbeschreibungen, fachliche Beschreibungen, Skizzen, Pläne, ... und noch ganz viel mehr...

[stan23]

Nachdem der Thread ja eh schon komplett abgedriftet ist, und es hierzu genauso viele verschiedene Sichtweisen gibt, ein kurzer Kommentar dazu:

Kommentare in Quellcode verstoßen meistens gegen das "Clean Code" Gebot, sind dadurch "anti pattern" und sollten vermieden werden.

Code: Alles auswählen

Comments rules:
   *  Always try to explain yourself in code.
   *  Don't be redundant.
   *  Don't add obvious noise.
   *  Don't use closing brace comments.
   *  Don't comment out code. Just remove.
   *  Use as explanation of intent.
   *  Use as clarification of code.
   *  Use as warning of consequences.

Wenn der Code also so komplex und undurchsichtig ist, dass man (Fachkraft) ihn auf dem ersten Blick nicht allein durch das anschauen des Codes versteht und es nur durch zusätzliche Kommentare im Quelltext möglich ist den Code nachzuvollziehen, dann ist der Code schlecht und sollte dringend überarbeitet anstatt durchkommentiert zu werden.

Widerspricht sich der Teil "keine Kommentare" nicht mit den letzten 3 Punkten?

Ich versuche mir gerade vorzustellen wie meine Ex-Kollegen und ich den Code hätten ändern können, so dass er ohne Kommentare auskommt. Oder ob es daran liegt dass wir keine Fachkräfte sind. Im Gegensatz zum Elektrikermeister ist das bei Programmierern schwieriger zu definieren, oder?

[funkleuchtturm]

Nachdem der Thread ja eh schon komplett abgedriftet ist

... ihr könnt hier auch über's aktuelle Fernsehprogramm diskutieren!
Der Thread hier ist sowieso nur noch eine Forumsleiche, nachdem ich meinen Leitartikel wegen der tollen Diskussionskultur gelöscht habe.

[deimos]

Hi,

der Gedanke bei Clean Code geht in Richtung kaum Kommentare und nicht dahin, Kommentare komplett zu verbannen.

Was auf jeden Fall verhindert werden sollte, ist ein Code in der Richung

Code: Alles auswählen

if (Bedingung) {
  // checks if Bedingung is true and do something
  DoSomething();
}

Genauso schwierig sind Kommentare, was eine (private) Funktion machen soll. Hier sollte man versuchen, die Methodensignatur so zu wählen, dass sie selbstsprechend ist. Ansonsten hat man leider ganz schnell das Problem, dass irgendjemand vergisst, den Kommentar zu ändern, wenn sich die Methode ändert.

Ganz allgemein ist es so, dass man in weit über 90% der Fälle unsauberen Code hat, wenn man einen Kommentar dran schreiben muss, damit es verständlich wird. Die absoluten Verfechter von Clean Code sehen aber leider nicht ein, dass man hin und wieder mal eine unsauberen Hack braucht. Die Kunst ist es, die Weitsicht zu haben, zu erkennen, wann das wirklich notwendig ist und wann es einem später auf die Füsse fallen wird.

Viele Grüße
Alex

[MichaelN]

nachdem ich meinen Leitartikel wegen der tollen Diskussionskultur gelöscht habe.

Das wiederum ist auch kein Zeichen einer tollen Diskussionskultur. Aber deine Entscheidung.

[Black]

Ich denke auch,wenn ich diesen Thread durchblätter, dass sich HIER doch die sachlich argumentativen Texte in der grossen Mehrheit befanden, während sich in dem , ich sag mal "provokativem KonkurrenzThread" dann dort auch die passenden Sätze fanden.

Aber dein Threadthema, deine Entscheidung.

Black

[ayngush]

Widerspricht sich der Teil "keine Kommentare" nicht mit den letzten 3 Punkten?

Das ist ja nicht absolut und Binär und alle anderen sind Ungläubige.
Die Auflistung ist ja eine Zusammenfassung dessen, was im Kontext "Clean Code" beim Erzeugen von Quellcode und Kommentieren von Quellcode möglichst berücksichtigt werden sollte, da dadurch der Code besser wird.
Niemand wird gekündigt, wenn man mal etwas kommentieren muss. Im Hinterkopf sollte man beim Programmieren halt behalten, dass man seinen Code für sich sprechen lassen können sollte. Kurz, Übersichtlich, nicht zu tief verschachtelt, möglichst ohne Wiederholungen, mit ordentlichen Benennungen von Variablen, Attributen, Klassen, Methoden, Funktionen, sich an die "Code Style" Richtlinien halten die sich etabliert haben, usw.
Halt das, was schon seit Ewigkeiten "rauf und runter" gebetet wird, was teilweise so schöne Namen wie "DRY" (Don't Repeat Yourself) und "KISS" (Keep It Small & Simple) trägt. Wenn man sich daran hält, dann braucht man auch nur ganz wenige Kommentare und die, die man dann erzeugt (weil sie sinnvoll sind) werden heutzutage ja meistens im "Javadoc / Docblock" Format zusammen gefasst.