Einzelnen Beitrag anzeigen

BKempf

Registriert seit: 1. Jun 2004
103 Beiträge
 
Delphi 6 Enterprise
 
#3

Re: Lines of Code: definieren, zählen

  Alt 6. Jun 2005, 17:00
Zitat von weltaran:
Ich muss bei meiner Arbeit die 'Lines of Code' ermitteln. Wie ist denn dieser Wert definiert?
- Kommentare zählen mit?
Nein. Die sind zwar nützlich zur Dokumentation, aber zum Code gehören sie imho nicht.
Natürlich machen Kommentare Arbeit; bei mir beträgt das Mengenverhältnis Code:Kommentare etwa 1:1, so daß ich im entsprechenden Fall einfach vorher einen höheren Preis pro LoC festlegen würde, um diese Arbeit mit zu erschlagen. Die Anzahl der Kommentarzeilen kann bei mir ohnehin stark schwanken, weil ich darin z.B. auch Beispiele für Spezialfälle (z.B. eines Funktionsaufrufs) unterbringe, die recht umfangreich werden können.
Compilerdirektiven stehen in Zeilen, die optisch Kommentaren entsprechen; sie wirken aber letztendlich auf die Arbeitsweise des Programms, so daß sie eigentlich mitzuzählen wären. Da sich ihre Zahl aber in Grenzen halten dürfte, ist das in der Regel mehr (Such- und Zähl-)Arbeit, als es letztlich einbringt.

Zitat von weltaran:
- begin/end?
Würde ich auf jeden Fall mitzählen (ebenso record/end, object/end, class etc.). Zwar schreibe ich begin/end/record etc. jeweils in eigene Zeilen, aber ohne sie würde sich das Programm völlig unerwartet verhalten.

Zitat von weltaran:
- Leerzeilen
Nein. Die dienen nur der Übersicht.

Als Faustregel würde ich sagen, daß ich genau das zählen würde, was ich (oder meine Firma, wenn Units aus Firmeneigentum verwendet werden) selbst geschrieben habe und was nicht fehlen darf, wenn das Programm identisch funktionieren soll (bzw. das Kompilat dasselbe sein soll).

Das bedeutet: Keine Kommentare oder Leerzeilen zählen. Compilerdirektiven nur dann, wenn das problemlos und schnell machbar ist.
Aber: Auch tote (nicht mehr verwendete) Funktionen, die der Compiler evtl. sogar schon wegoptimiert hat, nicht versehentlich mitzählen. Am besten aus dem Code entfernen; notfalls eine eigene kleine Code-Library aufbauen, um Sachen auszulagern, die im aktuellen Projekt überflüssig sind, aber später nützlich sein könnten.

Was sagt dein Auftraggeber?
The problem with troubleshooting is that sometimes the trouble shoots back.
  Mit Zitat antworten Zitat