Wieviel LOC pro Tag?
-
Xin schrieb:
hustbaer schrieb:
Ach Xin du Schelm.
Gemeint ist natürlich dass mehr LOC bei gleichem Feature-Set nicht unbedingt ein Indikator für "gut" ist. Genau so wie bei Flugzeugen mehr Gewicht bei gleichem Feature-Set nicht unbedingt gut ist.
(Und mit Feature-Set meine ich natürlich alles, also auch Dinge wie "wie Sicher ist das Ding" bei Flugzeugen oder "wie viel Bugs hat das Ding" bei Software.)Warum sollte das Feature Set gleich bleiben?
Weil ich mir ziemlich sicher bin dass das so gemeint ist.
Xin schrieb:
Wenn alles gleich ist, wäre ja kein Maßstab erforderlich, um etwas zu messen.
Jetzt hast du mich verloren.
Es ist ja nicht alles gleich. Beide Programme können das selbe, aber eins ist kürzer, und daher (bis auf die von mir bereits erwähnten Extremfälle) besser.
Das ist der Unterschied.-----
Ich schätze mal der Gates hat das inetwa so gemeint: Du hast nen Auftrag ein Programm mit Feature-Set X zu bauen. Und du misst den "Progress" Anhand der LOC die deine Programmierer raushauen.
Und das ist vergleichbar mit: du hast nen Auftrag ein Flugzeug mit Feature-Set X zu bauen. Und misst den "Progress" den deine einzelnen Ingenieure machen daran wie schwer das Zeugs das sie für's Flugzeug entwerfen ist.
"Progress" ist hier nicht als Fortschritt im Sinn von "fortschrittlich" zu verstehen, sondern wie beim Progress-Bar. Also wie sehr ein Programmierer/Ingenieure das Projekt vorantreibt in Richtung Fertigstellung.
Und das macht halt beides keinen Sinn.ps:
Bzw. auch wenn es um Fortschritt im Sinn von "fortschrittlich" geht macht es keinen Sinn. Wenn du die selbe Erweiterung (=> Fortschritt) von 10 Programmierern implementieren lässt, dann bekommst du 10 unterschiedlich lange Programme. Dabei wird so-gut-wie nie das längste das beste sein.
Insgesamt hat du zwar fast immer einen LOC-Zuwachs, aber einen unterschiedlich grossen.
-
Bashar schrieb:
Gibt es überhaupt kluge Metriken?
Ich bin sicher, Du willst auf die Postinganzahl raus.
(ps: +=1)
-
hustbaer schrieb:
Um das kürzest mögliche Programm zu machen, musst du viele Umformungen machen, die zu sehr schlechter Lesbarkeit führen. z.B. Hilfsvariablen für Zwischenergebnisse entfernen oder Funktionen die nur an genau einer Stelle aufgerufen werden dort inlinen. Das ist schonmal schlecht, weil es sehr nützliche Informationen entfernt, nämlich die Namen dieser Hilfsvariablen bzw. Funktionen.
Und dann geht's erst mit den wirklich bescheuerten Dingen los
Jaaa…
Also wenn wir beide und messen, wer am wenigsten LOC für das selbe Problem verwendet, dann wirds ein Hacker-Contest. Das ist Quatsch.
Also ich hab da so meinen Stiefel wie ich gerne rumproggere und mache halt so Sachen, wie daß ich innere Schleifen(mit eigenständiger Bedeutung) sauoft auslagere, was mich dann {} mal nicht gezählt 2 LOC kostet. Und Monsterklassen mag ich nicht, was mich dann pro Fragmentklasse(mit eigenständiger Bedeutung) 10 LOC kostet. Und so rotze ich den Code coll mit unnötigen Zeilen.
Macht aber nix, das ist so ungefähr, wie die Kosten, die man zahlt, um eine Liste in ein Array zu stopfen, um sie zu sortieren.Ich bin dicht an den minimalen LOC, würde ich denken. Ein Faktor 2 kümmert keinen.
-
Ich schrüb doch schon:
hustbaer schrieb:
Natürlich ist auch das Programm mit den wenigsten LOC nicht das beste. Das Optimum liegt irgendwo mitten drin - aber erfahrungsgemäss näher am Minimum als am Durchschnitt.
War das nicht klar genug?
-
volkard schrieb:
Bashar schrieb:
Gibt es überhaupt kluge Metriken?
Ich bin sicher, Du willst auf die Postinganzahl raus.
(ps: +=1)Du bist ja gerissen. Wie soll ich das denn bestreiten, ohne es gleichzeitig zu bestätigen? Indem ich mich auslogge :p
-
hustbaer schrieb:
Ich schrüb doch schon:
hustbaer schrieb:
Natürlich ist auch das Programm mit den wenigsten LOC nicht das beste. Das Optimum liegt irgendwo mitten drin - aber erfahrungsgemäss näher am Minimum als am Durchschnitt.
War das nicht klar genug?
Würde ich so nicht unterschreiben - da du durch gutes, flexibles Design oft viel Code generierst die zwar das direkte Problem nicht lösen aber Erweiterungen und Anpassungen an den Code erleichtern.
Wenn wir jetzt mal von etwas komplexeren ausgehen als Berechne fact N. Sondern zB sagen: implementiere einen HTTP Server.
Dann denke ich ist kürzerer Code kein indikativ für guten Code.
-
hustbaer schrieb:
Ich schrüb doch schon:
hustbaer schrieb:
Natürlich ist auch das Programm mit den wenigsten LOC nicht das beste. Das Optimum liegt irgendwo mitten drin - aber erfahrungsgemäss näher am Minimum als am Durchschnitt.
War das nicht klar genug?
Ich bestätigte Dich. Ich wiederholte Dich in anderen Worten, um es
anderenmir klar zu machen.Ok, Shade Of Mine hat eine Insel mit Faktor 4 gefunden. Aber damit hat sichs. Deppencode hat Faktor 100 mehr und den sieht man oft. Hab mal eine handgeschriebene C-Datei mit 400k gesehen und der Entwickler hat sich nicht geschämt. Gehts noch?
-
@volkard
Ah
Dachte es wäre als Korrektur gemeint.@Shade Of Mine
Wenn du von expliziten Plugin-Schnittstellen sprichst, dann könnte man fast schon wieder sagen dass die beiden Programme nicht mehr das selbe Feature-Set haben.
Wenn du nur "Vorbereitung auf eventuelle Erweiterungen" meinst, dann ... ui. Also da ist meine Erfahrung: lieber nicht machen bevor man weiss was man braucht. Weil man erfahrungsgemäss immer für das vorbereitet was man dann nie braucht.Ich hab' nix gegen gutes Softwaredesign. Single-Responsibility-Principle, Dependency-Injection (basic, also ohne Framework/Container) etc. führen auch zu viel Boilerplate-Code, das ist schon alles OK.
Aber ansonsten lieber YAGNI/KISS. Wenn man dann erweitern muss, dann kann man ja refactoren. Wenn man darin Übung hat geht das auch relativ flott. Und wenn man keine Übung darin hat, dann schreibt man schlechten Code. Weil keine Übung bedeutet dass man es selten macht, und wenn man es selten macht räumt keiner den Mist wieder zusammen den so-gut-wie jeder so-gut-wie immer beim 1. oder 2. Ansatz fabriziert.
-
hustbaer schrieb:
@volkard
Ah
Dachte es wäre als Korrektur gemeint.Ich kriege es einfach nicht hin, mich klar auszudrücken, sorry,
Andauernd meinen alle Leute, ich hätte was ironisch gemeint. Das ist nicht der Fall. Ich meine nie was ironisch.
Merkt Euch das mal bitte.
-
hustbaer schrieb:
Ich hab' nix gegen gutes Softwaredesign. Single-Responsibility-Principle, Dependency-Injection (basic, also ohne Framework/Container) etc. führen auch zu viel Boilerplate-Code, das ist schon alles OK.
Aber ansonsten lieber YAGNI/KISS. Wenn man dann erweitern muss, dann kann man ja refactoren. Wenn man darin Übung hat geht das auch relativ flott. Und wenn man keine Übung darin hat, dann schreibt man schlechten Code. Weil keine Übung bedeutet dass man es selten macht, und wenn man es selten macht räumt keiner den Mist wieder zusammen den so-gut-wie jeder so-gut-wie immer beim 1. oder 2. Ansatz fabriziert.
Damit machst du es dir viel zu einfach.
Du brauchst keine komplexen Plugin Schnittstellen definieren um den Code leicht anpassbar zu machen.Klar kannst du jetzt mit bla bla kommen wie "dann sind die Programme nicht mehr 100% gleich" aber sobald du komplexe Probleme löst, hast du komplexe Lösungen.
Ich finde es einfach viel zu simpel das wieder alles auf die Codelänge zu reduzieren. Code länge und Qualität stehen in keiner Relation zu einander.
Man kann Sachen sehr ausführlich machen und sehr abgekürzt. Keines von Beiden ist von vornherein besser. Oft ist das auch eine Frage wie sicher sich das Team in einer Domaine bewegt. Denn das Zeilen schreiben ist beim Programmieren immer der trivialste und schnellste Part.
Das wird scheinbar gerne vergessen. Das tippen, das produzieren des Codes selber, ist eigentlich vernachlässigbar wenig beim Programmieren. Deshalb kann eine Metrik die du auf diese Zeilen legst immer nur einen verschwindend geringen Teil der Arbeit messen.
-
Shade Of Mine schrieb:
Klar kannst du jetzt mit bla bla kommen wie "dann sind die Programme nicht mehr 100% gleich" aber sobald du komplexe Probleme löst, hast du komplexe Lösungen.
Ich bin mir nicht 100% sicher was du damit meinst.
Aber falls ich dich richtig verstehe...Für mich ist es natürlich ein signifikanter Unterschied, ob ein Programm mit z.B. der Anforderung beauftragt/konzipiert wurde, dass es ohne Schnittstellenänderungen erweiterbar sein muss -- oder eben nicht. *
Bei kleinen bis mittelgrossen Projekten die nicht vom Kunden "customized" werden, die keine SDKs/Frameworks/APIs sind gegen die Kunden eigene Software entwickeln etc., sondern einfach nur ganz normale Programme sind die halt irgendwas tun, macht es nach meiner Erfahrung keinen Sinn all zu viel vorauszuplanen.
Das heisst nicht dass man grundlegende Prinzipien des Software-Design misachtet, aber es heisst dass man nicht signifikant viel Code schreibt für etwas was man nicht braucht.Das führt aber dazu, dass man bei Änderungen - wie schon erwähnt - öfters mal refactoren muss. Was dann u.U. einige Schnittstellen "bricht". Wenn das Programm allerdings "am Stück" bearbeitet werden kann, dann macht das nix, weil im Zuge des Refactoring einfach alle Stellen die von diesen Schnittstellen abhängig sind angepasst werden.
Das ist aber natürlich ein KO für bestimmte Arten von Software - einige Beispiele hab' ich ja schon erwähnt.
Den Hinweis auf die Signifikanz dieses Unterschied als "blabla" abzutun halte ich nicht für sinnvoll.
Deswegen hab' ich auch "Feature-Set" und nicht "Funktion" geschrieben. (Ein bessere Begriff ist mir nicht eingefallen. Falls du einen besseren weisst lass es mich wissen.)
* Nur ein Beispiel - gibt viele Möglichkeiten. Genau so könnte es sein dass die Schnittstellenänderungen grundsätzlich egal ist, aber die Zeilenanzahl der Änderung möglichst klein bleiben muss. Kann für Genehmigungen von Folgeversionen wichtig sein. Oder dass es mit wenig RAM auskommen muss, mit wenig CPU-Power, ...
Bei manchen Projekten ist es auch wichtig dass das Programm branch/merge/cherrypicking-freundlich ist. Was auch wieder erfordert dass man sich vorab viel Gedanken macht und viel Zeit investiert, um das Design zu finden mit dem man am längsten ohne gröbere Refactorings auskommen wird.
-
Shade Of Mine schrieb:
Wenn wir jetzt mal von etwas komplexeren ausgehen als Berechne fact N. Sondern zB sagen: implementiere einen HTTP Server.
Dann denke ich ist kürzerer Code kein indikativ für guten Code.
Kannst du mal 1-2 konkrete Beispiele geben lang gut vs. kurz schlecht?
Es gibt viele Dinge wo es gut ist etwas längeren Code zu haben, und wo "etwas" u.U. auch 2x oder 3x so viel sein kann.
Nur kann ich ja nicht wissen was du meinst, also kann ich auch nicht sinnvoll darauf antworten.
-
volkard schrieb:
Ich meine nie was ironisch.
Und das ist auch gut so. Geht mir ähnlich. Alleine schon deshalb weil es Viele nicht kapieren.
-
Shade Of Mine schrieb:
Ich finde es einfach viel zu simpel das wieder alles auf die Codelänge zu reduzieren. Code länge und Qualität stehen in keiner Relation zu einander.
Man kann Sachen sehr ausführlich machen und sehr abgekürzt. Keines von Beiden ist von vornherein besser. Oft ist das auch eine Frage wie sicher sich das Team in einer Domaine bewegt.
Wie gut sich jemand in einer Domäne auskennt ist elementar, um Code zu produzieren. Eine dieser Domänen ist die Programmier-Sprache. Ich sage dann davon, dass man eine Programmiersprache sprechen kann, ob man Rhethorik der Sprache kennt oder gar ein Dichter ist.
Mit Mehrfachvererbung und generischer Programmierung kann man häufig LOC sparen. Qualitative Entwickler sind also an den LOC durchaus zu erkennen: Sie produzieren weniger LOC für das gleiche Feature. Damit produzieren sie hoffentlich mehr Features/LOC. Hier muss man eher einen Ausgleichsfaktor einbringen, um sie vergleichbar zu halten.
LOC sind nie ein Maß, um einen einzelnen zu bewerten. Sie sind nur ein Maß, um alle Entwickler an einem Projekt bzw. eben das Projekt zu bemessen. Dann sind 1000, 10000 oder 100k LOC je nach Projektgröße mehr oder weniger aber im Unschärfebereich der Schätzung.
Die Information, dass ein Projekt um die 1'000'000 +/- 100'000 LOC besitzt ist daher durchaus sinnvoll und wenn der Projektmanager abschätzen kann, ob seine Entwickler eher "Normalentwickler" sind oder eher schneller, bzw. langsamer.
-
Xin schrieb:
Die Information, dass ein Projekt um die 1'000'000 +/- 100'000 LOC besitzt ist daher durchaus sinnvoll und wenn der Projektmanager abschätzen kann, ob seine Entwickler eher "Normalentwickler" sind oder eher schneller, bzw. langsamer.
Nope. Nur schlechte Projektmanager schauen sich die Menge an Codezeilen an.
Der geschriebene Code ist der geringste Aufwand an einem Programm. Die wenigste Zeit fliesst in die Anzahl der Codezeilen. Die meiste Zeit wird damit verbracht nicht Codezeilen zu tippen.
Wir hatten zB letztens ein Projekt wo ein Entwickler ein Modul geschrieben hat mit 150-250 Zeilen und 2 andere Entwickler alles andere mit 5000-10000 Zeilen.
Wer war produktiver? Wer war schneller? Wer war besser? Wer hat mehr zum Projekt beigetragen?
Das kannst du anhand der Zeilen nicht feststellen. Ist der eine Entwickler so langsam? Hat er zuwenig Zeit investiert? Oder waren seine ~200 Zeilen einfach nur unendlich komplexer als der Rest des Projektes?
@hustbaer:
Bitte: ich spare Codezeilen in dem ich boost::format verwende anstatt es ueber C++ streams zu loesen. Ich spare sagen wir 10 Zeilen weil format eben weniger Zeilen braucht.Der Code ist aber schlechter geworden weil ich nur fuer 10 Zeilen mir die komplette boost Abhaengigkeit herein geholt habe und ploetzlich die Buildscripte komplexe werden.
Kuerzer Code aber schlechtere Qualitaet. Code Laenge und Code Qualitaet stehen in keinem Verhaeltnis zueinander. Kurzer Code kann schlecht sein, Langer Code kann schlecht sein.
Bei einem Musikstueck, einem Buch, einen Bild, etc. bewertest du die Qualitaet ja auch nicht nach der Laenge, oder?
Ihr denkt alle nur in so simplen Bahnen wie einen einzelnen Algorithmus und Jemand der fact N in weniger Zeilen implementieren kann ist besser. Aber zB alleine solche Entscheidungen welche Libraries verwendet werden sind viel essentieller fuer ein Projekt als wie kurz ein fact N ist.
Und zB bei der Wahl der Libraries zaehlt die Anzahl der Codezeilen die notwendig sind um damit etwas zu machen ueberhaupt nicht. Es zaehlt wie Robust sie ist, wie Flexibel und wie die Entwicklung in der Zukunft aussieht.
Wir haben zB am Freitag einen Parser geschrieben fuer Geolocation Daten um diese in Google Maps zu visualisieren. Das hat sicher 50-70 Zeilen Code benoetigt. Diese 50-70 Zeilen Code sind unnoetig fuer die Funktionalitaet der Webapp. Man koennte ja auch die Geolocation Daten hardcoded einbauen, das wuerde weniger Codezeilen kosten. Wir haben jetzt aber die Moeglichkeit die Daten aus Excel direkt zu uebernehmen wenn sich etwas aendern sollte. Ist das ein Software Feature? Nein, der Endkunde hat davon keinen Vorteil. Wir sparen uns damit nur Zeit in der Entwicklung wenn sich die Daten aendern.
Diese 50-70 Zeilen haben also gegenueber den vorherigen 5-10 Zeilen keine relevante Funktionalitaet mehr - beides visualisiert die Daten. Aber eine Loesung ist dennoch besser als die Andere.
LOCs sagen nichts aus. Garnichts.
-
Shade Of Mine schrieb:
LOCs sagen nichts aus. Garnichts.
mit zumindest 2 Ausnahmen:
Tage mit negativen LOC/d sind oft die besten
Wer in 10 Zeilen eine Funktion programmiert, für die ein durchschnittlicher Entwickler 100 und ein schlechter 1000 brauchen, ist wohl ziemlich gut (oder hat die besser geeignete Programmiersprache gewählt)
-
Shade Of Mine schrieb:
Bitte: ich spare Codezeilen in dem ich boost::format verwende anstatt es ueber C++ streams zu loesen. Ich spare sagen wir 10 Zeilen weil format eben weniger Zeilen braucht.
Der Code ist aber schlechter geworden weil ich nur fuer 10 Zeilen mir die komplette boost Abhaengigkeit herein geholt habe und ploetzlich die Buildscripte komplexe werden.
Ich finde diese Aussage ziemlich stark überspitzt! Ob ich jetzt <irgendeine_std_lib> mache, oder "boost_bla.h", ist doch erst mal egal. Und "boost_bla.h" macht doch nicht den Code komplexer! Und wenn du 10 Zeilen Code sparst, macht das die Sache weniger komplex.
Ok: Eine Abhängigkeit zu einer Lib macht das Build-Skript komplexer, aber:
1. Wie oft verbringst du deine Zeit mit Build-Skripts?
2. Hält sich das mit CMake doch in Grenzen, oder? Ich kenne mich damit eigentlich nicht aus, aber es war kein großes Problem für mich glut und OpenGl einzubinden. Mit sbt kann ich Libs sogar mit nur einer Zeile einbinden. Evtl. gibt es etwas ähnlich gutes auch für C++.L. G.,
IBV
-
IBV schrieb:
2. Hält sich das mit CMake doch in Grenzen, oder? Ich kenne mich damit eigentlich nicht aus, aber es war kein großes Problem für mich glut und OpenGl einzubinden. Mit sbt kann ich Libs sogar mit nur einer Zeile einbinden. Evtl. gibt es etwas ähnlich gutes auch für C++.
Biicode. Einfach #include schreiben, bii find laufen lassen, bii cpp:build laufen lassen, fertig. Funktioniert nur leider noch nicht mit boost, packen gerade noch andere Libraries auf ihre Server.
-
Shade Of Mine schrieb:
@hustbaer:
Bitte: ich spare Codezeilen in dem ich boost::format verwende anstatt es ueber C++ streams zu loesen. Ich spare sagen wir 10 Zeilen weil format eben weniger Zeilen braucht.Der Code ist aber schlechter geworden weil ich nur fuer 10 Zeilen mir die komplette boost Abhaengigkeit herein geholt habe und ploetzlich die Buildscripte komplexe werden.
Wenn man für 10 Zeilen eine Libraray wie Boost reinzieht kann man darüber diskutieren. Vor allem weil man in dem Fall die 10 Zeilen nicht wirklich spart, denn Build-Skripte etc. muss man natürlich auch dazurechnen.
Wenn man das aber öfter braucht, und diese 10 Zeilen an 10 oder gar 100 Stellen im Programm wiederholt, dann läuft was schief. Dann muss man sich entweder selbst eine Funktion schreiben mit der man diese 10 oder 100 Stellen zu je 10 Zeilen durch 10 oder 100 Stellen zu je 1-2 Zeilen ersetzen kann, oder auf was fertiges wie Boost zurückgreifen.
Shade Of Mine schrieb:
Kuerzer Code aber schlechtere Qualitaet. Code Laenge und Code Qualitaet stehen in keinem Verhaeltnis zueinander. Kurzer Code kann schlecht sein, Langer Code kann schlecht sein.
Bei einem Musikstueck, einem Buch, einen Bild, etc. bewertest du die Qualitaet ja auch nicht nach der Laenge, oder?
Der Vergleich mit Musik oder Bildern hinkt mir zu sehr als dass ich darauf eingehen wollen würde.
Der Vergleich mit Büchern ist nicht SO verkehrt.
Und natürlich ist ein (Sach-)Buch mit 100 Seiten vermutlich besser, wenn es mir exakt die selbe Information vermittelt, wie ein anderes Buch mit 1000 Seiten.Shade Of Mine schrieb:
Ihr denkt alle nur in so simplen Bahnen wie einen einzelnen Algorithmus und Jemand der fact N in weniger Zeilen implementieren kann ist besser.
Und du denkst anscheinend dass wir einfach alle doof sind, und versuchst gar nicht zu verstehen wovon wir reden (schreiben)
Shade Of Mine schrieb:
Wir haben zB am Freitag einen Parser geschrieben fuer Geolocation Daten um diese in Google Maps zu visualisieren. Das hat sicher 50-70 Zeilen Code benoetigt. Diese 50-70 Zeilen Code sind unnoetig fuer die Funktionalitaet der Webapp. Man koennte ja auch die Geolocation Daten hardcoded einbauen, das wuerde weniger Codezeilen kosten. Wir haben jetzt aber die Moeglichkeit die Daten aus Excel direkt zu uebernehmen wenn sich etwas aendern sollte. Ist das ein Software Feature? Nein, der Endkunde hat davon keinen Vorteil. Wir sparen uns damit nur Zeit in der Entwicklung wenn sich die Daten aendern.
Und genau das ist ein Feature. Das längere Programm kann etwas was das kürzere nicht kann. Damit sind sie nicht mehr vergleichbar. Die Frage ist dann nur ob das was das längere Programm mehr kann, auch wertvoll ist. Wenn ja, dann ist eh alles OK.
Wenn ich hier "Features" schreibe, dann meine ich nicht nur das was den Endkunden interessiert, sondern auch Dinge die nur die Programmierer interessieren. Ich hatte gehofft dass ich das in meinen bisherigen Beiträgen ausreichend klar gemacht hätte.
-
hustbaer schrieb:
Und du denkst anscheinend dass wir einfach alle doof sind, und versuchst gar nicht zu verstehen wovon wir reden (schreiben)
Gute Beschreibung.
