Lines of Code: definieren, zählen

[weltaran]

Hi Leute!

Ich muss bei meiner Arbeit die 'Lines of Code' ermitteln. Wie ist denn dieser Wert definiert?
- Kommentare zählen mit?
- begin/end?
- Leerzeilen

Wenn ich mit Delphi das Projekt 'erzeuge', dann steht in der Info eine ziemlich hohe Zahl, wie ist diese denn dort berechnet?

Ciao

weltaran

[alzaimar]

Deine erste Frage sollte der Aufgabensteller (Prof? Lehrer?) beantworten.
Delphi zeigt, wie viele Zeilen es kompiliert hat. Dazu zählt u.U. auch die komplette VCL.
Klar, Du kannst ein 'Hello World' Programm schreiben, per 'BUILD' alles kompilieren (wobei Du die VCL-Sourcen im Pfad mit angibst) und das dann deinem Prof geben. Das wären ca. 100.000 Zeilen. Der wird Augen machen.

[BKempf]

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?

[Phoenix]

Zitat von weltaran:

Ich muss bei meiner Arbeit die 'Lines of Code' ermitteln. Wie ist denn dieser Wert definiert?

Gar nicht. Das ist ja das Problem. Deswegen verwenden nur noch wenige Unternehmen das Maß LoC (und diese Unternehmen wird es voraussichtlich nicht mehr lange geben), weil es eigentlich gar nichts über ein Projekt aussagt bzw. diese ermittelten Werte aufgrund der Uneinheitlichkeit und der vollkommen fehlenden Aussagekraft zwangsläufig komplett misinterpretiert werden müssen. Das Mittel der Wahl wären hier FunctionPoints, aber das hat sich offenbar noch nicht in den Kreisen die mit den Zahlen arbeiten müssen / wollen herumgesprochen.

Aber zurück zur Frage: Wenn man LoC verwendet, dann gehören Kommentare genauso zur Zählung wie normaler Code. Wenn man hergeht und die ursprüngliche Idee hinter den LoC hernimmt, dann ist das ein Maß der Produktivität: LoC / Zeiteinheit. Natürlich sind Kommentare aus produktiver Arbeit entstanden und gehören deshalb zwingend in die Produktivitätsmessung hinein.

Idealerweise sollte man automatisch generierten Code nicht mit dazuzählen, da dieser ja nicht durch den die Produktivität des Mitarbeiters erstellt wurde - aber das lässt sich nunmal nicht oder nur extrem aufwändig auseinanderhalten. Das ist im übrigen noch ein Argument, warum man von der Verwendung von LoC als Maß absehen sollte.