Wieviel LOC pro Tag?

[Xin]

EOP schrieb:

10 - 30 LOC/Tag
Das wären etwa zwischen 1 und 4 Zeilen/Std

Wenn ich hier nicht nur rundrum verarscht werde dann fange ich wieder an zu arbeiten.

Meine "Lieblingsprogrammiersprache"...

public class HelloWorld {  // 2 Fehlermöglichkeiten: public vergessen, Hello World falsch geschrieben

        public static void main(String[ ] args) // public, static, main, Argumente, kann alles falsch sein, tut aber nix.
        {
              // Ausgabe Hello World!
              System.out.println("Hello World!");  // <- eine Zeile Code.
        }
}

So ein Hello World ist wie ein Roland Emerich-Film: Hier gibt's viel zu gucken, aber unglaublich wenig Handlung.

Der Code deckt sich mit dem Hello World aus Python.

print "Hello World\n"

Beides produzieren die gleiche Ausgabe, beide 1 LOC, aber Python hat dafür keinen Boilerplate.

EOP schrieb:

Da schaffe ich ja sogar in ASM manchmal 2 Zeilen/Std.

mov eax, ecx

und jetzt ne Std. frei?

hehehe, ja, wenn Du garantieren kannst, dass sie zwei Zeilen auf Dauer korrekt sind.

Dafür brauchst Du vielleicht einen Test. Und wenn Du dann nach einer Stunde weiterschreibst und feststellst, dass eine von den beiden Zeilen doch nicht zum Algorithmus passt, dann musst du die Zeile ändern und hast in der nächsten Stunde schon 50% mehr Arbeit zu leisten.
Zwischendurch Recherchieren, was Du eigentlich entwickeln sollst, Tests entwickeln, das über 10 Jahre warten - kommen am Schluss 10 Zeilen raus.
Es sind eben nicht die hunderte Zeilen, die sich mancher vorstellt.

Die Chance in Assembler aufwendig zu debuggende Fehler zu machen ist gegeben. Ich habe auch Programme mit GUI in Assembler gemacht, ich bin mir da wirklich für nichts zu schade. Aber ich benutzte viele Macros. Gutes Assembler ist nicht wirklich weit von C entfernt. Aber wenn Du einen echten Bug hast, dann wirst Du tierisch ausgebremst und das reduziert Deine Ausbeute. Und so stehst Du dann am Ende doch mit relativ wenig Zeilen da. Die Macros müssen ja auch erstmal fehlerfrei sein. Und ein if oder while oder strlen in C ist relativ gut abgetestet, wie auch ein a = b+1; einfach praktischer ist Expressions in ASM-Manier runterzubeten.

Shade Of Mine schrieb:

LOC ist eine sinnlos dumme Metrik.

Hmm... jain. Sie ist dumm um die Produktivität zu messen, aber ein Indiz um Komplexität und Aufwand einer Software zu messen. LOC ergibt keinen Sinn, wenn man nur 3 Bildschirmseiten oder einen Algorithmus misst, aber als Maß für eine Software durchaus. Gute und schlechte Programmierer gleichen sich bezogen auf die LOC ja aus, es kommt ein Maß für einen Norm-Programmierer raus.
Nun kann man abschätzen, wieviel Normprogrammierer-Jahre man für ein Problem braucht, sofern man das Problem in der Größe ungefähr einordnen kann.

Shade Of Mine schrieb:

Da schreibe ich vielleicht 100 Zeilen im Jahr (neue Features die alle heiligen Zeiten mal kommen ausgenommen).

Ich habe das mal mit meinem privaten Projekt durchgerechnet. Ich bin unglaublich produktiv, obwohl es ja nur in der Freizeit stattfindet.
Mit Deiner beruflichen Produktivität gleicht sich das ja wieder aus

Ich bin im Beruf äußerst produktiv. Ein von mir erzeugtes .cpp hat 43000 Zeilen, der dazugehörige Header mit inline-Funktionalität 57000. Macht 100000 Lines, abzüglich Deklaratives. Sagen wir 50000 LOC. Alleine die 2 Dateien ergeben dann 200LOC/d. Und die laufen sehr zuverlässig.

Wenn man jetzt noch verschweigt, dass die beiden Dateien von einem Python-Skript mit 1300 Zeilen (5,2 LOC/d) erzeugt werden, klingt das richtig gut.
Verschweigt man das nicht, bleibt mir vorrangig die Erweiterungen zu den generierten Klassen mit 1800 Zeilen (7,2 LOC) zusätzlich zu besagtem Python-Skript, womit ich auf 12,4 LOC/d komme. Das Debuggen bringt ja in der Regel keine neuen Zeilen.

Ich gleiche meine privaten LOC/d beruflich also auch wieder aus. Ganz einfach, weil ich im Beruf in einem großen Projekt arbeite und privat im Vergleich noch im Aufbau bin.

Shade Of Mine schrieb:

Alleine der Boilerplate für diese Projekte sind viele hundert Zeilen.

Boilerplate zählt nicht.

Shade Of Mine schrieb:

Ein neues Feature für eine Software sind sehr viele Zeilen. Einen Bug fixen sind idR keine neuen Zeilen und Refactoring entfernt sogar Zeilen.

Deshalb weiß man, sobald Jemand von LOCs zu reden anfängt was man von ihm halten muss.

Yepp... auf kurze Sicht gar nichts, auf sehr lange Sicht hat man ein Indiz, mehr nicht.

Bitte ein Bit schrieb:

Xin schrieb:

Ich mache meine Bugs aber lieber selbst. Darin bin ich aber schlecht, wenn ich im Jahr zwei Bugs bekomme, die ich selbst verschuldet habe, ist das viel.

Den Satz verstehe ich nicht ganz. Das erscheint mir zu wenig.
Was verstehst du unter einem Fehler?

Einen Quellcode, den ich zur Verwendung von Kunden oder anderen Entwicklern freigegeben habe und der nicht tut, was ich beabsichtigt habe. Das landet bei uns in Bugzilla.

Da landen bei mir auch "Bugs", wo sich Kollegen meinen Code gegriffen haben, bevor ich ihn vorgestellt und zur Verwendung freigegeben und melden, dass ein Feature nicht funktioniert. Liegt das daran, dass ich das Feature noch gar nicht entwickelt habe, ist das für mich kein Bug. Ist das Feature noch in aktiver Entwicklung, ist das für mich kein Bug, sondern unfertig.

Anderes Beispiel: Ich schreibe einen Im- und Exporter für ein aufwendiges Datenformat - siehe 100kLoc generierter Code. Diese 700 Klassen, die dafür generiert werden, haben auch individuelle Aufgaben, die ich Stück für Stück nachreiche. Der Im- und Exporter ist aber bereits im Kunden-Einsatz.
Dann kommt der Kunde an und meldet "Diese Datei funktioniert nicht" und ich bekomme eine Bugmeldung. Das ist ein Bug, wenn etwas nicht einzulesen ist, obwohl ich das bereits fertig programmiert hatte (oder dachte, es wäre fertig). Es ist kein Bug, wenn ich bei einem "not yet implemented" lande. Wenn der Support mir nun 10 Bugs schreibt, weil 10 Dateien aus den gleichen Gründen nicht einzuladen sind... dann ist das 1 Bug - oder eben auch gar keiner, wenn der Grund "not yet implemented" ist. Aber dann habe ich wenigstens neue Testdateien, die ich nutze bevor ich die entsprechenden Code-Stellen für die Öffentlichkeit freigebe.

Für einen Bug muss von mir in Code manifestierter Irrtum vorliegen. Ein Not-Yet-Implemented ist der Irrtum des Projektleiters, dass man bei Bugzilla nicht nur Bugs schreiben, sondern auch Feature-Requests formulieren kann. Ein Feature-Request ist aber eben kein Bug.

Bitte ein Bit schrieb:

Es gibt ja diverse Arten von Fehlern. Von einem Designfehler angefangen zu einfachen Abstürzen, falsche Berechnungen, Portabilitätsfehlern, Compiler Fehler, inkonsistentem Verhalten oder auch algorithmische Fehler,...

Alles ist Bug, wenn das Verhalten nicht meinem Wunsch entspricht, sobald ich den Code zur Nutzung freigegeben habe.

Bitte ein Bit schrieb:

// WinAPI Beispiel zu Portabilitätsfehler: 
// Ich öffne einen "Datei speichern..." Dialog ohne die Bedeutung von WINVER verstanden zu haben.
OPENFILENAMEW ofn = {0};

ofn.lStructSize = 54;  // Hinter lStructSize steckt ein wenig mehr als nur die Größe des Structs.

#ifndef OFN_EXPLORER
#define OFN_EXPLORER 0x00080000  // Auch ein Klassiker der WinAPI Programmierung
#endif
ofn.Flags = OFN_OFN_EXPLORER;
GetSaveFileName(&ofn)

// Kleiner Flüchtigskeitsfehler
std::string FileName = "C:\Benutzer\Kaiser Wilhelm\Info.doc";
std::string CmdLine = std::string("wordpad.exe") + FileName;

system(CmdLine.c_str());

Ich habe keine Ahnung von dem Klassiker der Windowsprogrammierung, ich vermute aber dringend, dass die OPENFILENAMEW nicht ausreichend initialisiert ist.
Ansonsten springt nur ins Auge, dass die Backslashs nicht escaped sind und der Name ohne Leerzeichen an "wordpad.exe" angeklebt wird. Welcher genau ist der Flüchtigkeitsfehler?

[Bitte ein Bit]

// WinAPI Beispiel zu Portabilitätsfehler:
// Ich öffne einen "Datei speichern..." Dialog ohne die Bedeutung von WINVER verstanden zu haben.
OPENFILENAMEW ofn = {0};

ofn.lStructSize = 54;  // Hinter lStructSize steckt ein wenig mehr als nur die Größe des Structs.

#ifndef OFN_EXPLORER
#define OFN_EXPLORER 0x00080000  // Auch ein Klassiker der WinAPI Programmierung
#endif
ofn.Flags = OFN_OFN_EXPLORER;
GetSaveFileName(&ofn)

Hast recht, das Struct ist nicht komplett ausgefüllt. Aber das Hauptproblem ist lStructSize und die eigentwillige Definition von OFN_EXPLORER. Der Kern dahinter ist das WINVER Präprozessorflag, welches angibt für welche Windows Version ich entwickle. In der WinAPI dürfte folgendes stehen, wobei ich aber von der WinAPI abweiche, da ich keine Lust habe das exakte Beispiel zu suchen. Es kommt nur auf die WINVER Geschichte an.

#if WINVER > 0x600 			// Erst ab Windows 7 funktioniert die Explorer Ansicht 
#define OFN_EXPLORER 0x00080000
#endif
typedef struct
{
  //...
  #if WINVER > 0x600 			// Erst ab Windows 7 haben wir zusätzliche Flags für die Steuerung der Anzeige.
  int ExFlags;			// Liste von zusätzlichen Flags zur Steuerung des Dialogs
  #endif
} OPENFILENAMEW;

Wenn ich ofn.lStructSize auf die maximale Größe von OPENFILENAMEW setze, und WINVER kleiner als 0x600 ist, provoziere ich einen Zugriff auf nicht initialisierten Bereich (ExFlags). Ich möchte ja, und das sagt der Code, Features von Win7 nutzen, obwohl ich nicht für Win7 entwickele sondern auch für WinXP!

std::string FileName = "C:\Benutzer\Kaiser Wilhelm\Info.doc";
std::string CmdLine = std::string("wordpad.exe") + FileName;

system(CmdLine.c_str());

Erster Fehler, klar die fehlende doppelte Escape Sequenzen. Den zweiten Fehler erkennt man, wenn man CmdLine betrachtet:

wordpad.exe C:\Benutzer\Kaiser Wilhelm\Info.doc

-> Fehlermeldung von Wordpad: Kann Datei C:\Benutzer\Kaiser nicht öffnen!
-> Ein Leerzeichen auf der Kommandozeile ist ein Trenner für Argumente
-> wordpad.exe "C:\Benutzer\Kaiser Wilhelm\Info.doc"

[dot]

William Henry Gates III schrieb:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

[Xin]

dot schrieb:

William Henry Gates III schrieb:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Hmm... ist ein typischer Gates. Sieht erstmal gut aus und man fühlt sich genötigt zu nicken und zu sagen "Recht hat er!".
Aber man sollte nicht drüber nachdenken.

Der Kitty Hawk Flyer wog etwa 275kg und flog mit einer Person Zuladung 59 Sekunden.
Eine Curtiss C-46R aus den 40ern wiegt 13.290 kg und hob maximal 12t.
Ein A330 wiegt 120t, mit maximaler Zuladung wiegt das Ding 250t.
Wenn man den A330 zerlegt, passt er in den Frachtraum einer Antonow An-225, die 175 t wiegt. Für die 130t Zuladung und Kerosin der A330 ist im Laderaum der Antonov auch noch Platz, maximal darf die Antonov 600t wiegen.

Gewicht von Flugzeugen ist durchaus ein Maßstab für den Fortschritt im Flugzeugbau. Einer von vielen, aber durchaus ein bisher zuverlässiges Indiz. Je schwerer das Flugzeug, desto mehr Fracht.

Wie LOCs.

Die Wahrscheinlichkeit 600000kg mit einem 275kg Flugzeug zu transportieren ist in nächerer Zukunft wohl eher nicht gegeben. Ähnlich sieht es aus, Windows 3.11 (3000000loc = 5*600000loc) in (1375 Zeilen = 5*275 Zeilen) zu realisieren.
Mehr Zeilen sind also durchaus ein Indiz auf mehr Features und Fortschritt.

Außer man vergleicht C mit DOS.
Um Windows 3.11 in einer Batch-Datei zu rufen, reicht auch eine Zeile.

[hustbaer]

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

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.

[Shade Of Mine]

Xin schrieb:

Shade Of Mine schrieb:

LOC ist eine sinnlos dumme Metrik.

Hmm... jain. Sie ist dumm um die Produktivität zu messen, aber ein Indiz um Komplexität und Aufwand einer Software zu messen.

Nein. LOC ist sinnlos und dumm. Nichts anderes. In Pascal habe ich mehr LOCs als in C. In Bash habe ich mehr LOCs als in Python.

Je nach Library gehen die LOCs rauf und runter. Verwende ich zB das Facebook SDK direkt, habe ich massig LOCs für simple Aufgaben, verwende ich die korrekt gekapselten Bundles, habe ich kaum LOCs.

LOCs sagen nichts aus.

LOC ergibt keinen Sinn, wenn man nur 3 Bildschirmseiten oder einen Algorithmus misst, aber als Maß für eine Software durchaus. Gute und schlechte Programmierer gleichen sich bezogen auf die LOC ja aus, es kommt ein Maß für einen Norm-Programmierer raus.
Nun kann man abschätzen, wieviel Normprogrammierer-Jahre man für ein Problem braucht, sofern man das Problem in der Größe ungefähr einordnen kann.

Unterschiedliche Aufgaben produzieren unterschiedliche LOCs. Wir haben zB einen Guru bei uns, der kaum LOCs produziert, aber seine Zeilen sind eben die kompliziertesten.

Eine Zeile Code hat komplett unterschiedliche Komplexitäten. Man kann die nicht miteinander vergleichen.

Shade Of Mine schrieb:

Alleine der Boilerplate für diese Projekte sind viele hundert Zeilen.

Boilerplate zählt nicht.

Und was genau ist Boilerplate Code denn?
Da gibt es keine Definition. Ist eine Schleife Boilerplate? Was ist mit einer Klassendefinition?

Du kannst hier natürlich wieder frei erfundene Metriken anwenden ob eine Zeile Code nun unter Boilerplate fällt oder nicht - aber das ist objektiv nicht möglich.

LOC ist eine Dumme Metrik. Nichts aber auch garnichts sagt sie aus. Nicht mal den Hauch eines Indikators. Und wie bereits gesagt, Jemand der LOCs für irgendetwas anderes als eine lustige Zahl ansieht, den kann ich nicht ernst nehmen. Sorry. Ich meine wir duellieren uns in der Arbeit auch mit wer die meisten Commits und die meisten LOCs bei einem Projekt gemacht hat, aber wir machen das aus Spaß, weil es lustig ist Zahlen zu vergleichen. Aber derjenige mit den wenigstens LOCs kann dennoch die meiste Arbeit gemacht haben und umgekehrt. LOC und Produktivität steht in keinem Verhältnis zueinander. LOC ist eine lustige Zahl die Spaß macht um zu Zeigen wer den größten e-penis hat. Aber das war es auch schon.

[Bashar]

Gibt es überhaupt kluge Metriken? Meiner aus leidvoller Erfahrung gespeisten Meinung nach sind Metriken untaugliche Krücken. Ich finde es schon fast menschenverachtend, kreative Arbeit anhand irgendwelcher leicht zu messenden Zahlen zu beurteilen. Nach welcher Metrik ist die Mona Lisa zu beurteilen? Größe eher klein, Anzahl der Farben, Krümmungsradius der Mundwinkel? Es geht nichts über das Lesen von Code, und die einzige sinnvolle "Metrik" ist die Anzahl der WTFs pro Minute dabei.

[Xin]

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? Wenn alles gleich ist, wäre ja kein Maßstab erforderlich, um etwas zu messen.
Wichtig wäre bestenfalls die Sprache gleich zu lassen, da eine spezialisierte Sprache in ihrem Umfeld logischerweise kürzer ist als eine nicht spezialisierte Sprache.

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.

Bei gleichen Featureset... wieso ist dann das Programm mit den wenigsten LOCs nicht das beste?

Per Batchfile braucht 1 Zeile um Windows 3.11 zu programmieren. Also ich habe Windows nie mit 3 Millionen Zeilen Code geschrieben, sondern immer DOS benutzt, wenn ich ein Windows brauchte.

Wundert mich, dass Microsoft nicht gleich in DOS programmiert hat, das ist doch viel effizienter. Irgendwo muss es da doch noch einen Haken geben. Ah... die Sache mit der spezialisierten Sprache...

[hustbaer]

Xin schrieb:

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.

Bei gleichen Featureset... wieso ist dann das Programm mit den wenigsten LOCs nicht das beste?

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

[volkard]

Bitte ein Bit schrieb:

Shade Of Mine schrieb:

LOC ist eine sinnlos dumme Metrik.

Das Problem ist auch, dass bei einer Beurteilung nach LOC die Entwicklung sich anpasst und es schnell zu einem Copy-Paste-Modify Vorgehensmodell kommt. Und das ist ja bekanntlich nicht sonderlich gut und gleicht einem Schneeballsystem. Solange das Ganze noch junfräulich ist, sieht alles gut aus. Aber die letzten Entwickler im System haben die Arschkarte gezogen.

Der erste, der an die Kundenzufriedenheit denkt, der erste, der möchte, daß sein Unternehmen nicht mit Karacho an die Wand fährt, der hat satt die wenigsten LOC und fliegt.
*helau*

[hustbaer]

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.

[volkard]

Bashar schrieb:

Gibt es überhaupt kluge Metriken?

Ich bin sicher, Du willst auf die Postinganzahl raus.
(ps: +=1)

[volkard]

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.

[hustbaer]

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?

[Bashar^]

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

[Shade Of Mine]

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.

[volkard]

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?

[hustbaer]

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

[volkard]

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.

[Shade Of Mine]

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.