![]() |
AW: Quellcode Kommentieren
Zitat:
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. |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
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 |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
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. |
AW: Quellcode Kommentieren
Zitat:
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; |
AW: Quellcode Kommentieren
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 |
AW: Quellcode Kommentieren
Zitat:
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 |
AW: Quellcode Kommentieren
Ich denke es kommt auch auf die Größe des Projekt-Teams an. Wenn es nur zwei Entwickler gibt, dann gibt es kein Projektmanagement.
|
AW: Quellcode Kommentieren
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:
nicht kommentiert werden bei einem
inc(i)
Code:
wäre ich mir da nicht so sicher.
if boolean(shl(shr(wert,1),1) then
Gruß K-H |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
Das Issue- und Projektmanagement darf aufatmen, JIRA soll nicht abgeschafft werden ;) |
AW: Quellcode Kommentieren
Zitat:
Delphi-Quellcode:
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.
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 ... |
AW: Quellcode Kommentieren
Zitat:
Delphi-Quellcode:
sein, gemeint war
Word
Delphi-Quellcode:
, was ich aber auch erst einige Dutzend Zeilen später bemerkt habe.
if wert>3 then
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 |
AW: Quellcode Kommentieren
Zitat:
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... |
AW: Quellcode Kommentieren
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ß |
AW: Quellcode Kommentieren
Zitat:
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
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 |
AW: Quellcode Kommentieren
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? |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
Sherlock |
AW: Quellcode Kommentieren
Zitat:
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 |
AW: Quellcode Kommentieren
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat:
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:
Refactoring > Methode Extrahieren uvm., auch von Fremdanbietern (GExperts, cnPack, ...) |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
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. |
AW: Quellcode Kommentieren
Zitat:
Ü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 |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
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. |
AW: Quellcode Kommentieren
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. :roll: |
AW: Quellcode Kommentieren
Zitat:
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
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:
Sind bis heute meine besten Kunden - aber auch die anspruchsvollsten. Egal, BTT. |
AW: Quellcode Kommentieren
Zitat:
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. |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
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ö". |
AW: Quellcode Kommentieren
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.
|
AW: Quellcode Kommentieren
[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. |
AW: Quellcode Kommentieren
Zitat:
Zitat:
Gruß K-H |
AW: Quellcode Kommentieren
Zitat:
Ich meine eher das Verbergen von kodierter Logik ('Status=3 AND RemovalOptions in (3,4,27)') in Views, SP, UDF etc. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz