Quellcode Kommentieren

Sicherlich lässt sich alles auch nach Dejan Vu's Vorstellungen lösen, die ich teilweise echt gut finde. Man kann aber auch eine Zeile Kommentar schreiben anstatt eine Prozedur auf 5 aufzusplitten. Das ist dann wohl Geschmackssache.

Richtig, aber der Kommentar wird bei Änderungen nicht(immer) mitgepflegt. Irgendwann hat der Kommentar nichts mehr mit dem Code zu tun. Dann lieber gleich aufsplitten. Bei Berechnungen ist das aber blödsinnig, außer, wenn Zwischenergebnisse irgendetwas Erhellendes ergeben oder für Prüfungen notwendig sind. Bei diesen Berechnungen verwendet man gerne kurze Bezeichner, wie a, alpha, m oder n. Das sind zwar aus codeästhetischer Sicht 'ganz schlimme' Bezeichner, aber jeder Mathematiker würde dir einen Vogel zeigen, wenn Du dann 'Fläche', 'Winkel', 'Matrixzeilenanzahl' und 'Matrixspaltenanzahl' schreiben würdest. Das ist im mathematischen Kontext usus, diese besonderen kurzen Bezeichner zu verwenden. Wichtig ist, das man das kapiert. Als Programmierer stoß ich mich ja auch nicht an 'i' und 'j' für Zähler: Also, alles immer im Rahmen.

Zitat:

Wer aber Zeit hat andere Leute wegen ihrer Kommentare in einem Meeting zu befragen

Nein, nein. Beim wöchentlichen Meeting werden von mir Best Practices, Patterns oder Knallkorken gezeigt und erklärt. Und wenn jemand zu faul war, Code zu verbessern, dann zeig ich das auch und erinnere an die Pfadfindertugend: "Hinterlasse den Code immer etwas sauberer, als Du ihn vorgefunden hast". Namen werden nie genannt, außer, jemand hat was Tolles gemacht, dann kriegt er ein Bienchen

. Bei Stilblüten lachen wir uns alle mehr oder minder schlapp, nur einer bekommt einen roten Kopf und lacht vielleicht etwas gekünstelt. Aber es ist egal, wer das war.

**Namenloser**

Zitat von Dejan Vu:

Zitat von Headbucket:

Sicherlich lässt sich alles auch nach Dejan Vu's Vorstellungen lösen, die ich teilweise echt gut finde. Man kann aber auch eine Zeile Kommentar schreiben anstatt eine Prozedur auf 5 aufzusplitten. Das ist dann wohl Geschmackssache.

Richtig, aber der Kommentar wird bei Änderungen nicht(immer) mitgepflegt.

Beim Funktionsnamen gibt es allerdings auch kein Naturgesetz, dass der automatisch mitgepfegt wird.

Zitat von Namenloser:

Beim Funktionsnamen gibt es allerdings auch kein Naturgesetz, dass der automatisch mitgepfegt wird.

Natürlich nicht. Wenn ich jedoch den Namen anpasse, sind automatisch alle selbstdokumentierenden Codestellen, die diese Methode verwenden, mit geändert. Und damit auch deren Dokumentation.

**Sherlock**

Dann jetzt mal Spaß beiseite: Bist Du hauptberuflicher Codereviewer? Weil das Zeitargument ist für mich äusserst nachvollziehbar. Freilich wird die jetzt gesparte Zeit später doppelt bis dreifach beim Bugfixing bezahlt, aber der Projektdruck ist nunmal jetzt und nicht in drei Monaten.

Sherlock

Ich arbeite als Architekt, Review und Entwickler, letzteres immer weniger.

Es ist nicht mehr Arbeit, wenn man die Methoden auf "3-Zeiler" herunterbricht. Im Gegenteil: Eine Umsetzung ist so wirklich viel viel schneller, weil sie meistens auf Anhieb läuft (bis auf die üblichen Schusseligkeitsfehler). Natürlich: Ich mach das seit Ewigkeiten (vor 30 Jahren jieß0 das Top-Down und 'stepwise refinement')und ich denke gar nicht mehr darüber nach, aber jedesmal, und wirklich jedes Mal, wenn ich in alte Ich-frickel-mir-schnell-Code-zusammen-ist-doch-wurscht-wie-das-aussieht verfalle, verfluche ich nach spätestens drei Erweiterungen mein anfängliches Gewurschtele.

Mein Tipp an Alle: Fangt mit Clean Code an. Nicht bis zum bitteren Ende, aber so, das man keine Kommentare benötigt, die den Code erklären. Der Code muss sich selbst erklären. Im Idealfall muss das ein englischer Satz (oder maximal 3-5) sein. 'If the customer is valid, then charge fees' ist wirklich 1:1 in Delphi abbildbar (das 'the' kann man weglassen). Schade, das es Linq für Delphi nicht gibt, da geht das noch besser.

Ach, und natürlich benötigt man richtiges Werkzeug. Ich bin auf C# umgestiegen und arbeite mit Resharper, da kann man sehr viel Refactoring ratzfatz schnell durchziehen. Codeschnipsel markieren => Methode extrahieren => Parameter benennen => fertig. Geht so -glaube ich- nicht in Delphi, oder?

**Stevie**

Zitat von Dejan Vu:

Schade, das es Linq für Delphi nicht gibt, da geht das noch besser.

Ach, und natürlich benötigt man richtiges Werkzeug. Ich bin auf C# umgestiegen und arbeite mit Resharper, da kann man sehr viel Refactoring ratzfatz schnell durchziehen. Codeschnipsel markieren => Methode extrahieren => Parameter benennen => fertig. Geht so -glaube ich- nicht in Delphi, oder?

Du hast gerade den Hauptgrund genannt, warum sich diese Cleancode Mentalität in der Delphi Community noch nicht so stark verbreitet hat, wie in anderen Sprachen. Unsere Tools dafür sind teilweise einfach Grütze.

**Sherlock**

Zitat von Stevie:

Zitat von Dejan Vu:

Schade, das es Linq für Delphi nicht gibt, da geht das noch besser.

Ach, und natürlich benötigt man richtiges Werkzeug. Ich bin auf C# umgestiegen und arbeite mit Resharper, da kann man sehr viel Refactoring ratzfatz schnell durchziehen. Codeschnipsel markieren => Methode extrahieren => Parameter benennen => fertig. Geht so -glaube ich- nicht in Delphi, oder?

Du hast gerade den Hauptgrund genannt, warum sich diese Cleancode Mentalität in der Delphi Community noch nicht so stark verbreitet hat, wie in anderen Sprachen. Unsere Tools dafür sind einfach Grütze.

Amen!

Sherlock

Zitat von Stevie:

Du hast gerade den Hauptgrund genannt, warum sich diese Cleancode Mentalität in der Delphi Community noch nicht so stark verbreitet hat, wie in anderen Sprachen. Unsere Tools dafür sind einfach Grütze.

Na ja. 20 Jahre Pascal mit top-down gingen auch ohne refactoring Tools.

Am Code herumkneten, bis er noch besser wird (speziell Bezeichner umbenennen)... stimmt, Codepflege und die Pfadfindermentalität: Geht ohne Tools wirklich nicht/bzw. schlecht.

Aber stepwise refinement, Probleme in kleine Probleme zu unterteilen, am Anfang abstrakt und erst zum schluß konkret zu werden, also lesbaren Code zu schreiben: Das mache ich schon immer so. Und vor ein paar Jahren hab ich dann gelesen, das das wohl en vogue ist.

**p80286**

Zitat von Dejan Vu:

...wenn ich in alte Ich-frickel-mir-schnell-Code-zusammen-ist-doch-wurscht-wie-das-aussieht verfalle, verfluche ich nach spätestens drei Erweiterungen mein anfängliches Gewurschtele.

Na, die Erfahrung sollten eigentlich die meisten von uns schon gemacht haben.

Übrigens sind die Namen der Prozeduren beim Erstellen meist sehr einleuchtend und präzise. Nach einem Monat sehe ich das für mich doch etwas kritischer.

Gruß
K-H

**Stevie**

Zitat von p80286:

Zitat von Dejan Vu:

...wenn ich in alte Ich-frickel-mir-schnell-Code-zusammen-ist-doch-wurscht-wie-das-aussieht verfalle, verfluche ich nach spätestens drei Erweiterungen mein anfängliches Gewurschtele.

Na, die Erfahrung sollten eigentlich die meisten von uns schon gemacht haben.

Witzigerweise ist das aber die Argumentation, die ich oft höre, wenn es um sauberen Code, Einhaltung von bestimmten Praktiken etc geht. Für kleine Huschhusch Projekte oder irgendwas, was man nur alleine programmiert, braucht man sowas ja nicht... ja, nee is klar. Wenn man das schon nicht für nen banales Projekt macht und dort lernt, dann wird man das bestimmt bei nem Riesenprojekt perfekt beherrschen.