Quellcode Kommentieren

[mjustin]

Zitat:

Zitat von bernau (Beitrag 1267611)

Zitat:

Zitat von Dejan Vu (Beitrag 1267583)

Zitat:

Zitat von bernau (Beitrag 1267582)

Aber manchmal gibt es "unsinnige Wünsche" von Kunden. So etwas kommentiere ich immer. Teilweise sogar mit Verweis auf die E-Mail des Kunden.

Wir machen das über CVS.

Das interessiert mich. Wie sieht das in der Praxis aus? Der Hinweis auf den Kundenwunsch steht bei mir im Code und fällt sofort in's Auge. Wie sieht das im CSV aus? Wo steht der Hinweis? Muss ich selber aktiv einen Button drücken um diese Zusatzinfo zu sehen?

Delphi-Quellcode:

Procedure ZeigMalWas;
begin
  // 10.10.2012 - E-Mail von Meyer - Will ein Blinken im Sekundentakt.
  // LassBlinken(1);
  // 20.11.2012 - E-Mail von Müller - Blinken zu hektisch. Auf Wunsch nur alle 2 Sekunden.
  // LassBlinken(2);
  // 20.03.2013 - Telefonat mit Meyer - Vertrieb hat sich durchgesetzt. Blinken 2 mal pro Sekunde.
  LassBlinken(0.5);
end;

Ich kenne kein Versionskontrollsystem oder eine CSV-IDE Integration sie so etwas kann oder nur in die Nähe käme.

Alle gängigen Systeme (Git, SVN etc.) arbeiten dateiorientiert. Man kann sich also zu der Unit, in der Procedure Machwas enthalten ist, detailliert auflisten lassen wer wann und warum etwas an der Unit geändert hat. Sich aber nur auf Prozedurebene die Änderungen anzeigen zu lassen, ist mit den mir bekannten Werkzeugen nicht möglich. Müßte man mal recherchieren :)

Aber selbst wenn es möglich wäre, aus dem Versionskontrollsysteme ein Änderungsprotokoll einer einzelnen Prozedur zu generieren, dann wäre dieses Änderungsprotokoll damit nicht in der Unit selber sichtbar (so wie in obigem Beispiel), sondern nur ein Protokollfile oder ein in einem Logviewer dargestellter Text.

Versionskontrollsysteme erleichtern die Arbeit aber doch sehr: wenn eine Kundenänderung sich nicht nur auf eine einzige Stelle bezieht, sondern mehrere Units betroffen sind, muss ich nicht an allen Stellen einzeln dokumentieren, stattdessen wird beim Speichern der Änderung für alle geänderten Dateien der Bezug zum Kundenauftrag einmalig erfasst und ist im CVS Protokoll dann allen Units zugeordnet.

[JasonDX]

Zitat:

Zitat von mjustin (Beitrag 1267618)

Ich kenne kein Versionskontrollsystem oder eine CSV-IDE Integration sie so etwas kann oder nur in die Nähe käme.

Alle gängigen Systeme (Git, SVN etc.) arbeiten dateiorientiert. Man kann sich also zu der Unit, in der Procedure Machwas enthalten ist, detailliert auflisten lassen wer wann und warum etwas an der Unit geändert hat. Sich aber nur auf Prozedurebene die Änderungen anzeigen zu lassen, ist mit den mir bekannten Werkzeugen nicht möglich. Müßte man mal recherchieren :)

die meisten können Diffen, d.h. die Unterschiede zwischen den Änderungen anzeigen. Damit entdeckt man solche Sachen. Natürlich, wenn ein Submit 1200 solcher Änderungen betrifft, wirds schwierig - dann ist das aber die falsche Arbeitsweise.

[hoika]

Hallo,

beim Einchecken der Datei kann man das doch als Info eintragen.
Bei Tortoise-SVN kann ich so viel Text eingeben, wie ich will.
Checke ich genau diese eine Datei als eigene Revision ein,
kann ich bequem danach suchen.


Heiko

[mjustin]

Zitat:

Zitat von Stevie (Beitrag 1267613)

In einer Versionsverwaltung wäre das in der Historie. Wenn man den Code liest, interessiert doch nicht mehr, wie oft das mal vor Jahren geblinkt hat und warum.

Änderungen einer einzelnen Prozedur über die Jahre hinweg nachzuvollziehen ist mit einer Versionsverwaltung allerdings schon etwas mühsam. Da man immer nur ein Diff zweier Versionen macht, in dem auch alle anderen Änderungen der Unit enthalten sind. Ein praktisches Feature wäre es schon, die Evolution eines isolierten, definierten Codeabschnitts einer Unit auflisten zu können. Kann das ein aktuelles CVS?

[Bernhard Geyer]

Zitat:

Zitat von bernau (Beitrag 1267615)

Der Code ist hier natürlich nur ein Beispiel und natürlich steht nicht in jeder Procedure solch ein Kommentar. Meine Frage war ja, wie es im CSV aussieht? Fällt so etwas sofort in's Auge, oder muss ich eine Aktion durchführen um diese Info's zu lesen. Mir hat es schon oft geholfen, daß ich "zufällig" diese Kommentare gelesen habe.

Wir verwenden die Kombination CVS, Jira und Fisheye.
Man sieht welcher Issue/Fehler welche Quellcodeänderung verursacht hat. Man kann in der History der Änderungen suchen und vieles Mehr...

Dazu brauch ich dann den Quellcode nicht mit Änderungskommentaren verseuchen die nach einiger Zeit das "Man sieht den Wald vor lauter Bäumen nicht mehr"-Problem verursachen.

[mjustin]

Zitat:

Zitat von JasonDX (Beitrag 1267619)

Zitat:

Zitat von mjustin (Beitrag 1267618)

Ich kenne kein Versionskontrollsystem oder eine CSV-IDE Integration sie so etwas kann oder nur in die Nähe käme.

Alle gängigen Systeme (Git, SVN etc.) arbeiten dateiorientiert. Man kann sich also zu der Unit, in der Procedure Machwas enthalten ist, detailliert auflisten lassen wer wann und warum etwas an der Unit geändert hat. Sich aber nur auf Prozedurebene die Änderungen anzeigen zu lassen, ist mit den mir bekannten Werkzeugen nicht möglich. Müßte man mal recherchieren :)

die meisten können Diffen, d.h. die Unterschiede zwischen den Änderungen anzeigen. Damit entdeckt man solche Sachen. Natürlich, wenn ein Submit 1200 solcher Änderungen betrifft, wirds schwierig - dann ist das aber die falsche Arbeitsweise.

Ja, nur läßt sich kein mir bekanntes Diff über alle Revisionen auf einen bestimmten Codeabschnitt beschränken. Man müßte dazu alle Unterschiede, die sich nicht auf die interessierende Prozedur beziehen, ausfiltern können.

Ausgabe eines solchen prozedurbezogenen Diff wäre dann (vereinfacht, ohne + und - Marker für neue/gelöschte Zeilen) etwa wie folgt:

Code:

Diff for Procedure ZeigMalWas - Revision 1 to Head

---

Revision 1: 10.10.2012 - E-Mail von Meyer - Will ein Blinken im Sekundentakt.

Procedure ZeigMalWas;
begin
  LassBlinken(1);
end; 

---

Revision 4711: 20.11.2012 - E-Mail von Müller - Blinken zu hektisch. Auf Wunsch nur alle 2 Sekunden.

Procedure ZeigMalWas;
begin  
  LassBlinken(2);
end; 

---

Revision 65332: 20.11.2012 - E-Mail von Müller - Blinken zu hektisch. Auf Wunsch nur alle 2 Sekunden.

Procedure ZeigMalWas;
begin
  LassBlinken(0.5);
end;

[Sherlock]

Zum Thema IDE-Integration: VersionInsight Plus vom Uwe Schuster hat ein "LiveBlame" was in der IDE zu jedem Codeblock anzeigt in welcher Revision der sich geändert hat. Es ist dann ein leichtes sich die Commit-Kommentare dazu anzuschauen.

Sherlock

[vagtler]

Zitat:

Zitat von mjustin (Beitrag 1267618)

[...] Ich kenne kein Versionskontrollsystem oder eine CSV-IDE Integration sie so etwas kann oder nur in die Nähe käme. [...]

Sowas möchte ich auch auf keinen Fall im Code haben. Das gehört in das Issue-Management und wird durch Branching und zu den Issues zugeordneten Commits gemanaged.

Die Sachbearbeiter im Issue- und Projekt-Management würden sich bedanken, wenn sie so etwas im Code nachschlagen müssten. Vom Accounting gar nicht erst zu reden... :p

[bernau]

Ich denke es kommt auch auf die Größe des Projekt-Teams an. Wenn es nur zwei Entwickler gibt, dann gibt es kein Projektmanagement.

[p80286]

Interessante Diskussion.
Vor allem, weil die meisten wohl nicht die Probleme haben, die Chemiker angesprochen hat. Wenn man nicht mehr im Thema drin ist oder wenn einem die Entwicklungsoberfläche fehlt (ganz zu schweigen von einem Versionskontrollsystem), dann ist Kommentar im Sourcecode doch sehr hilfreich.

Natürlich muß

Delphi-Quellcode:

inc(i)

nicht kommentiert werden bei einem

Code:

if boolean(shl(shr(wert,1),1) then

wäre ich mir da nicht so sicher.

Gruß
K-H

[bernau]

Zitat:

Zitat von p80286 (Beitrag 1267658)

Interessante Diskussion.
Vor allem, weil die meisten wohl nicht die Probleme haben, die Chemiker angesprochen hat. Wenn man nicht mehr im Thema drin ist oder wenn einem die Entwicklungsoberfläche fehlt (ganz zu schweigen von einem Versionskontrollsystem), dann ist Kommentar im Sourcecode doch sehr hilfreich.

Das bringt es auf den Punkt.

[mjustin]

Zitat:

Zitat von vagtler (Beitrag 1267640)

Zitat:

Zitat von mjustin (Beitrag 1267618)

[...] Ich kenne kein Versionskontrollsystem oder eine CSV-IDE Integration sie so etwas kann oder nur in die Nähe käme. [...]

Sowas möchte ich auch auf keinen Fall im Code haben. Das gehört in das Issue-Management und wird durch Branching und zu den Issues zugeordneten Commits gemanaged.

Die Sachbearbeiter im Issue- und Projekt-Management würden sich bedanken, wenn sie so etwas im Code nachschlagen müssten. Vom Accounting gar nicht erst zu reden... :p

Nein, der Code soll natürlich nicht mit Versionsinformationen auf Prozedurebene zugemüllt werden. Nur für die Nachverfolgung von Änderungen wäre es eine feine Sache, wenn man das Changelog auf eine Prozedur anstatt auf eine Datei beschränken könnte. Und ich kenne kein Tool, das das kann. Und wenn, dann wäre dessen Integration ähnlich dem hier bereits genannten "LiveBlame" sicher sehr hilfreich.

Das Issue- und Projektmanagement darf aufatmen, JIRA soll nicht abgeschafft werden ;)

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1267658)

bei einem

Code:

if boolean(shl(shr(wert,1),1) then

wäre ich mir da nicht so sicher.

Refactoring:

Delphi-Quellcode:

function SecondBitIsSet(aValue : Integer) : boolean;
Begin
  result := boolean(shl(shr(aValue,1),1)
End;
...
// statt kryptisch
if boolean(shl(shr(wert,1),1) then

// nun verständlich
if SecondBitIsSet(Wert) then ...

Zum Changelog: Einfach pro Task einchecken. Es gehört Disziplin dazu, aber das lernt man. Spätestens wenn man schon wieder eine Teamrunde spendieren muss, weil man zu schlampig war (Ich weiß, wovon ich rede). Ich brauche kein Changelog pro Prozedur. Ich brauche ein Changelog für die Change Requests und Bugfixes. Das Diff und 'Blame' zeigt mir dann, wer was wann wo geändert hat. Braucht man eigentlich nur beim Review.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1267664)

Delphi-Quellcode:

function SecondBitIsSet(aValue : Integer) : boolean;

Leider hast du die Intention nicht getroffen. Wert sollte ein

Delphi-Quellcode:

Word

sein, gemeint war

Delphi-Quellcode:

if wert>3 then

, was ich aber auch erst einige Dutzend Zeilen später bemerkt habe.
Das ist mir in einem uralten TP-Programm über den Weg gelaufen. Leider konnte ich den Programmierer nicht mehr fragen warum er es so gelöst hat. Kommentar wäre da recht hilfreich gewesen.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1267685)

Leider hast du die Intention nicht getroffen.

Wieso 'Leider'? Mir doch wurst, war ja auch nur ein Beispiel.

Und wenn man sowas sieht, dann refaktorisiert man trotzdem. Wenn Du weißt, das das '>3' heißen soll, dann änderst Du das eben in '>3' oder schreibst ne Funktion 'HigherThanThree', was hier ein wenig dämlich wäre, aber den Kontext der Diskussion träfe.

Auf keinen Fall schreibt man als Kommentar dahinter: 'soll >3 bedeuten'. Wenn ich das sehe, zeige ich diesen Schnipsel im nächsten Meeting und frage, wieso der, der den Kommentar geschrieben hat, den Code nicht gleich refaktorisiert hat.....

PS: Ich hätte das durch einen Unit-Test abgesichert und da wäre mir dann schon aufgefallen, das da was nicht stimmen kann und den Namen angepasst...

[Headbucket]

Ich möchte auch mal meinen Senf dazugeben.

Ich habe vor 1 Jahr bei meiner jetzigen Firma begonnen und habe hier auch das Programmieren gelernt. Ich musste verschiedene Dinge an einem großen Projekt (mehr als 650000 Zeilen Code) erweitern.
Hier war ich auch extrem froh, dass ich oft gute Kommentare gefunden habe, die mir etliche Fragen erspart haben. Da die Units teilweise bereits 2000 erstellt wurde und die entsprechenden Leute nicht mehr in der Firma sind, hätte ich sowieso niemanden fragen können.

Ich stimme natürlich dem bisher gesagtem zu: Sinnlose Kommentare können wegbleiben und wenn es irgendwie geht, soll man die Funktion so benennen, dass sie logisch klingt.

Ich hatte aber z.B. oft mit sehr komplexen mathematischen Funktionen zu tun. Hier hätte ich mich ohne das Kommentar erstmal lange in die Materie einlesen müssen. So haben mir die Kommentare genau gesagt, welche Parameter ich übergeben muss. Die Parameter hatten natürlich auch aussagekräftige Namen, die mir aber als unwissender nicht weitergeholfen haben.

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.

Wer aber Zeit hat andere Leute wegen ihrer Kommentare in einem Meeting zu befragen...so viel Zeit möchte ich auch mal haben ;-)
Wir haben diese Zeit in unserer Firma (sehr kleines Entwicklerteam) nicht. Da hat niemand die Zeit jemand anderen seinen Code zu erklären bzw. durchzulesen. Wenn man dann doch mal Code eines anderen Programmierers verwendet, ist man über Kommentare sehr dankbar.

Gruß

[Dejan Vu]

Zitat:

Zitat von Headbucket (Beitrag 1267701)

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:

Zitat von Dejan Vu (Beitrag 1267705)

Zitat:

Zitat von Headbucket (Beitrag 1267701)

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.

[Dejan Vu]

Zitat:

Zitat von Namenloser (Beitrag 1267713)

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

:roll: 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

[Dejan Vu]

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:

Zitat von Dejan Vu (Beitrag 1267741)

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:

Zitat von Stevie (Beitrag 1267743)

Zitat:

Zitat von Dejan Vu (Beitrag 1267741)

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

[Dejan Vu]

Zitat:

Zitat von Stevie (Beitrag 1267743)

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. :-D

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1267593)

Hallo,

auch ich bin der Meinung, dass JEDE Methode kommentiert sein muss.
Spätestens, wenn sich jemand in etwas einarbeiten soll, ist das wichtig.
Allerdings ist der Kommentar der Methode ein Sache,
weit wichtiger sind aber die Parameter- und Returnwertbeschreibung.
Ich halte mich übrigens an die Syntax von DelphiCode2Doc.

Ich hab das die letzten Wochen auch mal bei einem Projekt gemacht, womit alleine das Unit-Interface von knapp 280 auf über 1800 Zeilen angewachsen ist, aber zum Glück kann man die sich Teile ausblenden zusammen falten lassen. (inzwischen über 3300 Zeilen, aber ich weiß jetzt nicht wie viel davon Code und wie viel Kommentare/Dokumentation sind)

Zitat:

Zitat von hoika (Beitrag 1267593)

Bsp:

Delphi-Quellcode:

{*
  vergleicht 2 Strings, ohne Groß- und Kleinschreibung zu beachten

  @param  S1  erster String
  @param  S2  zweiter String
  @return  <1 S1<S2, >1 S1>S2, =0 S1=S2
}
function CompareText(const S1, S2: String): Integer;

Ich bin selber mal in die Falle getappt, dass ich auf -1 geprüft habe, statt auf <1

Dass man aus diesen Kommentaren auch schön eine Dokumentation rausziehen kann,
also die Code-Beschreibung nicht doppelt schreiben muss, ist ein angenehmer Zusatznutzen.

PS: Es gibt dafür auch Konstanten, welche man verwenden könnte.

Delphi-Quellcode:

type
  TValueRelationship = -1..1;

const
  LessThanValue = Low(TValueRelationship);
  EqualsValue = 0;
  GreaterThanValue = High(TValueRelationship);

Mit DelphiCode2Doc nimmst du dir aber eine nette Funktion weg, welche es seit 2005/2006 im Delphi gibt.
=> Help-Insight

Anhang 41564 Und Delphi kann das inzwischen (XE2/XE3) selber zusammenfalten, ohne daß man die Regionen dafür benötigt.

Zitat:

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?

Doch. (teilweise)

Refactoring > Methode Extrahieren
uvm., auch von Fremdanbietern (GExperts, cnPack, ...)

[JasonDX]

Zitat:

Zitat von Sherlock (Beitrag 1267735)

Dann jetzt mal Spaß beiseite: Bist Du hauptberuflicher Codereviewer? Weil das Zeitargument ist für mich äusserst nachvollziehbar

Das ist eine reine Prioritäts-(und damit auch Management)-Frage. Tests sind ein ähnliches Zeitinvestment. Ich verbringe einiges an Zeit damit, Tests zu schreiben, und anderer Leute Code zu reviewen - aber das ist auch gut so. Da wird dann gern auch auf mangelnde, falsche oder unnütze Dokumentation hingewiesen. Das Problem das ich mit CodeReviews in anderen Firmen gesehen habe ist eher das, dass manche Entwickler nicht so gut mit Kritik an deren Implementierungen zurechtkommen.

[Dejan Vu]

Zitat:

Zitat von JasonDX (Beitrag 1267752)

...Das Problem ..ist .., dass manche Entwickler nicht so gut mit Kritik an deren Implementierungen zurechtkommen.

:roll: Jupp. Daher kritisiere ich direkt nur unter vier Augen und immer konstruktiv und positiv und, wenn im Meeting, immer anonym aber auch nur dann, wenn der keine Mimose ist. Denn er/sie fühlt sich ja angesprochen. Ich versuche, den Narzißmus und die Empfindlichkeit durch (hört sich blöd an) teambildende Maßnahmen zu minimieren. Von einem 'Freund' lässt man sich eher etwas erzählen, als von einem Konkurrenten. Ich unterstütze Teamprogramming und 'sich gegenseitig helfen'.
Ich habe aber das Glück, das das Team fast nur aus kompetenten Leuten besteht, die sich teilweise noch aus der Schule kennen und die Chemie stimmt einfach.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1267741)

...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:

Zitat von p80286 (Beitrag 1267762)

Zitat:

Zitat von Dejan Vu (Beitrag 1267741)

...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. :)

[OlafSt]

Clean Code lohnt sich auch auf andere, ungewöhnlichere Art:

Noch im letzten Jahrtausend (OMG, wie sich das anhört) schrieb ich eine Applikation, die via GSM-Modem irgendwo Daten abholte, decodierte und in einer SQL-DB verschwinden ließ. ich wechselte die Firma, wechselte die Firma, wechselte die Firma, lag im KH, machte mich selbständig.

Dann klingelt das Telefon - der Kunde von damals möchte ein paar Änderungen an dem Ding haben. 15 Jahre alter D7-Code. Da bist du froh, wenn du sauber gearbeitet und ein paar Kommentare hinterlassen hast.

[himitsu]

Zitat:

Zitat von OlafSt (Beitrag 1267797)

Dann klingelt das Telefon - der Kunde von damals möchte ein paar Änderungen an dem Ding haben. 15 Jahre alter D7-Code. Da bist du froh, wenn du sauber gearbeitet und ein paar Kommentare hinterlassen hast.

Kommt drauf an.

Wenn keiner den Code versteht, sondern nur noch du (etwas) und die dann auf dich zu kommen müssen, weil kein Anderer es kann, dann spräche CC eher dagegen. :roll:

[Stevie]

Zitat:

Zitat von OlafSt (Beitrag 1267797)

Da bist du froh, wenn du sauber gearbeitet und ein paar Kommentare hinterlassen hast.

Da stimme ich zu, persönlich versuche ich es mit Kommentaren so zu halten, dass ich nur dann welche schreibe, wenn der code nicht selbsterklärend ist (man wundert sich manchmal, wie schön das mit guter Architektur und Benennung zu lösen ist) und dann auch nicht, was der Code macht (das sieht man schließlich), sondern warum bzw mit welcher Intention.

Zitat:

Zitat von himitsu (Beitrag 1267799)

Wenn keiner den Code versteht, sondern nur noch du (etwas) und die dann auf dich zu kommen müssen, weil kein Anderer es kann, dann spräche CC eher dagegen. :roll:

Code der Kategorie versuchte Arbeitsplatzsicherung? :stupid:

[OlafSt]

Zitat:

Zitat von Stevie (Beitrag 1267801)

Code der Kategorie versuchte Arbeitsplatzsicherung? :stupid:

Nä, so'n Murks mach ich nicht. Hab ich auch nie. In meiner ersten Anstellung als Programmierer wurde mir auf nette, aber bestimmte Art das Teamplay beigebracht. Nett, weil es echt Spaß machte und nicht als Schinderei empfunden wurde. Bestimmt, weil Zuwiderhandlungen unangenehm geahndet wurden ;)

However, ich habe diesen Stil konsequent bis heute durchgehalten und ich hätte keine Bedenken, irgendein Projekt an jemanden weiterzugeben, ohne meine Präsenz neben ihm/ihr. Er/Sie wird wenig Probleme haben, sich da reinzufuchsen.

However.

Zitat:

Wenn keiner den Code versteht, sondern nur noch du (etwas) und die dann auf dich zu kommen müssen, weil kein Anderer es kann, dann spräche CC eher dagegen.

Ich denke eher, es war das Problem, einen Delphi-Entwickler aufzutreiben. Die sind dünn gesät und viel gefragt (weshalb es mir seit Jahren ein Rätsel ist, wieso ich keine Anstellung finden konnte). Die Jungs haben sich tatsächlich von Firma zu Firma gehangelt, um mich aufzuspüren. Ich hatte sogar noch ein Exemplar der Datenformatbeschreibung, die da aus dem angerufenen Gerät kam ;)

Sind bis heute meine besten Kunden - aber auch die anspruchsvollsten.

Egal, BTT.

[Dejan Vu]

Zitat:

Zitat von OlafSt (Beitrag 1267802)

Die sind dünn gesät und viel gefragt

Letzeres kann nicht sein, weil es nicht stimmen kann: Wenig Delphi-Entwickler produzieren wenige Projekte mit wenig Nachfrage zur Weiterentwicklung und wenig Nachfrage zur Teamvergrößerung. Ergo sind Delphi-Entwickler selten gefragt.

Bezüglich Kommentaren von Legacy-Code: Natürlich ist es besser, Code zu kommentieren, als ihn nicht zu kommentieren. Aber viel besser ist es eben (imho), den Code selbsterklärend zu schreiben, weil damit ja mehrere Fliegen mit einer Klappe erschlagen werden (Lesbarkeit, Wartbarkeit, Testbarkeit, Skalierbarkeit, Foobarkeit usw.)

Ich partizipiere heute noch von meinen Kommentaren in uralten SQL-Prozeduren, weil ich bis heute noch kein vernünftiges Verfahren anwende, um meine CC-Ansprüche auf SQL-Code anzuwenden.

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1267814)

Zitat:

Zitat von OlafSt (Beitrag 1267802)

Die sind dünn gesät und viel gefragt

Letzeres kann nicht sein, weil es nicht stimmen kann: Wenig Delphi-Entwickler produzieren wenige Projekte mit wenig Nachfrage zur Weiterentwicklung und wenig Nachfrage zur Teamvergrößerung. Ergo sind Delphi-Entwickler selten gefragt.

Wenig Delphi-Entwickler produzieren zwar wenig neues, aber unterschätze nicht die vorhandene Code-Basis, die evtl. erweitert oder gepflegt werden soll. Delphi gibt es ja nicht erst seit gestern.

[himitsu]

Zitat:

Zitat von OlafSt (Beitrag 1267802)

Ich denke eher, es war das Problem, einen Delphi-Entwickler aufzutreiben. Die sind dünn gesät und viel gefragt (weshalb es mir seit Jahren ein Rätsel ist, wieso ich keine Anstellung finden konnte). Die Jungs haben sich tatsächlich von Firma zu Firma gehangelt, um mich aufzuspüren.

Komisch, mir kam das mal so vor, als wenn die Firmen garnicht suchen.

Bin mal ganz einfach in eine der wenigen mit Delphi arbeitenden Firmen (laut Telefonbuch gab es nur 3, hier in der Gegend) und hab mehr aus neugier gefragt, wie es eigentlich so aus
sieht, als "doofer" Realschüler und ohne Delphi richtig gelernt zu haben (do it yourself), also ob man da eine Chance in diesem Beruf hätte.
Ohne mich richtig angeguckt zu haben, kam sofort die Antwort "Nö".

[mquadrat]

Bei anständiger Benennung kann man sich viele Kommentare sparen. Aber ich schreib mir teilweise ein paar Notizen rein, wenn Code Seiteneffekte haben kann bzw. hatte. Also sowas in der Art wie "Das muss man hier so machen, weil sonst an Stelle XY nix mehr geht". Wie die meisten hier haben wir es mit zum Teil 14 Jahre altem Code zu tun, damals hat man in der Delphi-Welt noch nicht so sauber gekapselt. Hauptsache RAD.

[Dejan Vu]

[QUOTE=bernau;1267829...unterschätze nicht die vorhandene Code-Basis, die evtl. erweitert oder gepflegt werden soll. Delphi gibt es ja nicht erst seit gestern.[/QUOTE] Mach ich nicht. Es gibt einfach verdammt wenig Firmen, die Delphi-Entwickler suchen, auch auf dem freien Markt. Mag ja sein, das es millionen von Delphi-Projekten da draußen gibt. Vermutlich sind die so endgeil programmiert und erfüllen alle Wünsche, das man einfach keinen Bedarf an Delphi-Programmierern hat. Wäre ja denkbar ;-)

Mal wieder OT geworden :oops: Schluß damit. Sry.

[p80286]

Zitat:

Zitat von mquadrat (Beitrag 1267849)

Bei anständiger Benennung kann man sich viele Kommentare sparen. Aber ich schreib mir teilweise ein paar Notizen rein, wenn Code Seiteneffekte haben kann bzw. hatte. Also sowas in der Art wie "Das muss man hier so machen, weil sonst an Stelle XY nix mehr geht". Wie die meisten hier haben wir es mit zum Teil 14 Jahre altem Code zu tun, damals hat man in der Delphi-Welt noch nicht so sauber gekapselt. Hauptsache RAD.

Ich denke das können die meisten unterschreiben.

Zitat:

Zitat von Dejan Vu (Beitrag 1267814)

Ich partizipiere heute noch von meinen Kommentaren in uralten SQL-Prozeduren, weil ich bis heute noch kein vernünftiges Verfahren anwende, um meine CC-Ansprüche auf SQL-Code anzuwenden.

da wird es einem aber auch nicht leicht gemacht, und wenn ich diese EinBustabenAliasse sehe, frag ich mich schon was die Autoren sich dabei denken.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1267877)

da wird es einem aber auch nicht leicht gemacht, und wenn ich diese EinBustabenAliasse sehe, frag ich mich schon was die Autoren sich dabei denken.

Einerseits, aber das ist das kleinere Übel. Aliase sind ja Abkürzungen, denn sonst könntest Du ja auch den Tabellennamen verwenden. Wenn man eine Nomenklatur hat, sodaß für die Kundentabelle immer der Alias 'kd' oder 'k' verwendet wird, dann geht das schon.

Ich meine eher das Verbergen von kodierter Logik ('Status=3 AND RemovalOptions in (3,4,27)') in Views, SP, UDF etc.