Wieviel LOC pro Tag?

[hustbaer]

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.

[EOP]

volkard schrieb:

Ich meine nie was ironisch.

Und das ist auch gut so. Geht mir ähnlich. Alleine schon deshalb weil es Viele nicht kapieren.

[Xin]

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.

[Shade Of Mine]

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.

[großbuchstaben]

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)

[Gast]

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

[Nathan]

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.

[hustbaer]

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.

[Skym0sh0]

volkard schrieb:

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.

War das jetzt ironisch gemeint?

[Shade Of Mine]

hustbaer schrieb:

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.

Und damit ist es unmoeglich 2 unterschiedliche Codes zu vergleichen - denn autotools brauchen ein eck mehr Code als zB CMake. Obwohl die Funktionaelitaet gleich geblieben ist.

Im Build Script eine Dependency angeben ist in CMake zB 1 Zeile.

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.

Du hast es nicht verstanden.

Es geht darum dass du eine Library verwenden kannst um LOC zu sparen. Und unterschiedliche Libraries sparen unterschiedliche Anzahl an LOCs.

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.

lol. Bücher und Musik sind Konzeptionell identisch.

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.
[...]
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.

Und das ist der Denkfehler.
Exakt selbe Information.

Gib 100 Programmieren eine mittelmaessig Kompexe Aufgabe und du bekommst 100 unterschiedliche Loesungen. Du argumentierst hier, dass es nicht moeglich ist diese Programme miteinander zu vergleichen, da sie nicht exakt das selbe tun. Damit bestaetigst du dass LOC nichts aussagt.

Denn jeder Programmierer baut andere Features in ein Programm ein. Und genau das ist der Grund warum LOC nichts aussagt - denn ein Einheitsprogramm gibt es nicht. Jeder Programmierer baut seine eigenen Features in ein Programm.

[hustbaer]

@Shade Of Mine
Und trotzdem bleibt der (mein) Erfahrungswert, dass längerer Code meist schlechter ist.
Ich habe versucht ein Paar Faktoren aufzulisten die vielleicht erklären können warum das so ist.

Anstatt darauf zu antworten dass du diesen Erfahrungswert bestätigen oder eben nicht bestätigen kannst, hast du versucht zu erklären warum es keine Korrelation geben kann. Was mMn. Unsinn ist, da das Thema viel zu komplex ist als dass man sämtliche Mechanismen die zu einer signifikanten Korrelation führen könnten erfassen kann.

[volkard]

hustbaer schrieb:

@Shade Of Mine
Und trotzdem bleibt der (mein) Erfahrungswert, dass längerer Code meist schlechter ist.

Shade ist auch der selben Meinung, mag ich meinen. So im normalen Bereich. Ihr fahrt Euch gerade an extremen Beispielen auf, fürchte ich.

Mein Erfahrungswert sagt, daß Shade sehr gesund auf beiden Beinen steht und ich unterschreibe ungelesen eine Expertise, die er abgibt. husti ist absolut auch firm. Es *kann* nur ein Mißverständnis sein, wenn Ihr beide meint, hier grundsätzlich anderer Meinung zu sein. "Bashar hat unrecht und Arcoth hat seinen Standard nicht gelesen" schreib ich in meine Sig, wenn Ihr nicht in 3 Postings Euch umarmt.

[hustbaer]

volkard schrieb:

Bashar hat unrecht und Arcoth hat seinen Standard nicht gelesen" schreib ich in meine Sig, wenn Ihr nicht in 3 Postings Euch umarmt.

Ich überlege mir gerade ob mir das noch weitere zwei Sinnlos-Beiträge in diesem Thread wert ist

[Bashar]

volkard schrieb:

"Bashar hat unrecht und Arcoth hat seinen Standard nicht gelesen" schreib ich in meine Sig, wenn Ihr nicht in 3 Postings Euch umarmt.

Ich liebe euch auch *schnüff* Vielleicht wirds mal wieder Zeit für ein Forentreffen.

[Xin]

Shade Of Mine schrieb:

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.

Das sehe ich anders, das hatte ich schon beschrieben...

Shade Of Mine schrieb:

Wer war produktiver? Wer war schneller? Wer war besser? Wer hat mehr zum Projekt beigetragen?

...aber offenbar kommt das nicht an.
LOC sind schlecht, um einen einzelnen zu beschreiben, LOCs sind aber ein Indiz, um ein Projekt zu beschrieben, um es abzuschätzen. Das ist immernoch keine exakte Wissenschaft, aber es ist ein Hilfsmittel. Eine Absicherung, ob man mit anderen Mitteln vielleicht komplett auf dem Holzweg ist ohne es zu merken.

Shade Of Mine schrieb:

Ihr denkt alle nur in so simplen Bahnen wie einen einzelnen Algorithmus

Du liest meine Postings nicht, bevor Du darauf eingehst, oder? Die Aussage ist hoffentlich genauso falsch, wie Deine, aber die Wahrscheinlichkeit dass ich richtig liege, erscheint mir höher.

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.

Du möchtest also damit feststellen, dass ihr statt ein Feature für den Kunden zu schreiben ein Feature für euch geschrieben habt und dass das deswegen kein Feature ist, deswegen die Codes identisch sind, aber per LOC nicht vergleichbar sind, weil sie ja nur für den Kunden identisch sind...!?

Ja, das ist logisch... es definiert zwar reichlich Begriffe um, aber wenn Du "Feature" umdefinieren darfst, dann darf ich auch "logisch" umdefinieren, oder?

hustbaer schrieb:

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)

Ich bin definitiv doof, da kannst Du jeden hier fragen ;-D

Shade Of Mine schrieb:

Gib 100 Programmieren eine mittelmaessig Kompexe Aufgabe und du bekommst 100 unterschiedliche Loesungen. Du argumentierst hier, dass es nicht moeglich ist diese Programme miteinander zu vergleichen, da sie nicht exakt das selbe tun. Damit bestaetigst du dass LOC nichts aussagt.

Häng die 100 Lösungen hintereinander, teile das durch 100 und Du bekommst die durchschnittliche LOC für die Lösung.

Nun gibt die Aufgabe erneut an 100 Entwickler und die durchschnittliche LOC wird ähnlich sein. Der einzelne Entwickler wird aber drüber oder drunter liegen.

Wenn wir uns an kleinsten Problemen festmachen, dann muss ich hustbaer zustimmen:

hustbaer schrieb:

@Shade Of Mine
Und trotzdem bleibt der (mein) Erfahrungswert, dass längerer Code meist schlechter ist.

Wenn ich beispielsweise Übungsaufgaben mit Studenten gemacht habe, kamen da meist aufwendige Überlegungen heraus. Dann haben wir versucht, die Idee zu vereinfachen. Eine einfachere Idee bedeutet, dass sie leichter verständlich ist. Und dass sie weniger Quelltext benötigt.
Mein Lieblingsbeispiel ist hier "Wörter zählen". Etwa 3/4 der Studenten zählen die Leerzeichen zwischen den Wörtern und addieren 1 dazu. Ich benutze die Übung, um den Leuten beizubringen, erst nachzudenken, was sie da tun.
Ich gebe ihnen dann einen leeren String, der dann laut deren Programm ein Wort enthält. Dann korrigieren sie das und ich füge zusätzliche Leerzeichen zwischen den Worten ein. Das wird korrigiert und dann zählen sie nur noch das erste Leerzeichen. Dann füge ich Leerzeichen vor dem Satz ein.
Die meisten fühlen sich in dem Moment ziemlich blöd. ^^
Selten muss ich noch Leerzeichen hinter dem letzten Wort einfügen.
Wir haben das auf proggen.org mal durchgespielt mit dem Ziel die schnellste Variante für das Problem Wörter Zählen zu suchen.

So sieht das dann etwa am Anfang aus:

unsigned int
    count = 1, // Word count
    i = 0;

  const char
    EOL = '\0', // End of line
    SPC = ' ';  // Space

  // Return if string is empty
  if ( ! str[0] ) return 0;

  // left trim
  while ( str[i++] == SPC )
  {
    if ( str[i] != SPC ) break;
    i++;
  }

  // count words
  while ( str[i++] != EOL )
  {
    if ( str[i] == SPC && (str[i+1] != SPC) ) count++;
  }

  // dirty: decrease last count if it is caused by a space character
  if ( str[i-2] == SPC ) count--;

  return count;

Irgendwann kommt man dann zu dem Schluss, dass man eigentlich Wörter statt Leerzeichen zählen will. Und weil es hier um Geschwindigkeit ging, waren Array-Zugriffe sowieso chancenlos.
Die beiden nachfolgenden sind von mir. Hier kann man die Idee des Algorithmus' auch eher ablesen: entweder im Wort oder außerhalb des Wortes. Und wenn man einen Wortanfang findet, zählt man es eben.

unsigned int counter = 0;

  while( *str )
    if ( *(str++) == ' ' )
      while( *str == ' ' && *str ) str++;  // Leerzeichen überspringen
    else
    {
      while( *str != ' ' && *str ) str++;  // Wort überspringen
      counter++;
    }

  return counter;

Noch einen Hauch kleiner und schneller ist:

unsigned int counter = 0;

  while( *str )
  {
    if ( *(str++) == ' ' )
      continue;

    while( *str != ' ' && *str ) ++str;  // Leerzeichen überspringen
    counter++;
  }

  return counter;

Es geht aber auch zu kürzer - und langsamer.

int c = 0;

   while ( *( str++ ))
      *str != ' ' && ( *( str-1 ) == ' '&&  c++ );

   return c;

Es geht also auch sehr kurz. Die letzte Variante wurde mir spontan von einem Kollegen frei aus dem Kopf ohne Test diktiert. Fehlerfrei. Die letzte Variante wird vielen aber unverständlich sein. Und da sie langsamer ist, würde ich sie als schlechter beschrieben.
Sie hat aber weniger LOC. Ich führe sie also auf, erstens um Shade in gewisser Weise recht zu geben, dass weniger LOC nicht grundsätzlich besseren Code bedeuten, andererseits habe ich diese Variante auch nur ein einziges mal angeboten bekommen von jemanden, der sich gedanklich wirklich bemüht alles in eine (1!) Expression zu packen. In jedem Fall sieht man, dass die Bandbreite, diese kleine Aufgabe mit viel oder wenig LOC zu lösen absolut deutlich auseinander geht.

Vergleichsweise langsam zu meinen Varianten war ohne Optimierung war dieser Quelltext (er fragt *str != ' ' pro Wort einmal zuviel ab):

int wc=0;

    while (*str != '\0')
    {
        if (*str != ' ')
        {
            wc++;

            while (*str != ' ')
                str++;
        }
        else
            str++;
    }

    return wc;

Mit der GCC Optimierung war dieser Quelltext schneller als mein nicht optimierter. Mein durch gcc optimierter Quelltext hingegen war langsamer(!) als die nicht optimiert kompilierte Variante. Dieser Quelltext (und zwei weitere) hat optimiert sogar meine Asm-Variante überholt. Alle optimierten GCC-Varianten haben eine andere Assembler-Variante überholt.

Es geht häufig um Nuancen, aber diese Nuancen waren bei uns immernoch im Bereich Faktor 2,5 bzw. 1,5 (gcc optimiert) von der schnellsten zur langsamsten Version. ^^

Erfahrungsgemäß sinken die LOCs aber je besser der Code wird, also weiter das Problem eingekocht wird. Aber eine gute Lösung im Schnitt immer um die 10 Zeilen, eine schlechte - bis auf die eine Ausnahme - immer länger.

Edit: /url->/quote Edit2: /quote->/code... narf

[Gast]

Was ist mit Trennung der Worte mit anderen Whitespaces, wie Tabs? (Ansonsten ein tolles anschauliches Beispiel)

[Xin]

Citizen42 schrieb:

Was ist mit Trennung der Worte mit anderen Whitespaces, wie Tabs?

In den Spielregeln wurde alles, was nicht Leerzeichen oder EOF ist als Wort behandelt. Das gilt auch für Satzzeichen. Z.b. "Hallo.Welt!" ist ein Wort.

Inspiriert ist die Aufgabe durch argv, in der die komplette Kommandozeile in einzelne Abschnitte unterteilt werden muss. Eine solche Funktion wurde im Studium benötigt, um eine eigene Shell zu schreiben und es zeigte sich, dass die Aufgabe hervorragend geeignet ist, Programmieranfänger zum Denken anzuregen.

Citizen42 schrieb:

(Ansonsten ein tolles anschauliches Beispiel)

Der komplette Kram findet sich hier.

[EOP]

Vor einigen Jahren hatte mein Bruder ein Projekt bei der Lufthansa.
War auf 100 oder so Mannjahre veranschlagt.

Mein Bruder hatte schon ganz am Anfang zu seinen Chefs gesagt "das wird so nix, Konzept taugt nix". Hat keiner zugehört.
Es ist nie was dabei rausgekommen weil das Konzept von Anfang an Quatsch war.

Die Programmierer haben in FFM den ganzen Tag nur gespielt oder geschlafen.

Nach einem Jahr hat mein Bruder gekündigt weil es ihm zu langweilig war (obwohl er über 6000 DM/Monat fürs Nixtun bekam).

[hustbaer]

Xin schrieb:

Es geht aber auch zu kürzer - und langsamer.

int c = 0;

   while ( *( str++ ))
      *str != ' ' && ( *( str-1 ) == ' '&&  c++ );

   return c;

Es geht also auch sehr kurz. Die letzte Variante wurde mir spontan von einem Kollegen frei aus dem Kopf ohne Test diktiert. Fehlerfrei. Die letzte Variante wird vielen aber unverständlich sein. Und da sie langsamer ist, würde ich sie als schlechter beschrieben.
Sie hat aber weniger LOC. (snip)

Ich hab - bevor die ganze Diskussion ausgeufert ist - schon geschrieben dass der ideale Code nie der kürzeste ist, sondern "etwas länger als der kürzeste". Aber - wieder ein Erfahrungswert - von der Länge her näher am kürzesten als am Durchschnitt.

Oder anders gesagt: ich hab schon viel schlechten langen Code gesehen, aber noch wenig schlechten kurzen Code.
Ausgenommen schlechten kurzen Code der schlecht war weil er zu wenig gemacht hat (z.B. Corner-Cases nicht abgedeckt, keine Fehlerüberprüfungen etc.). Hauptsächlich aus dem Grund hab ich die Sache mit "gleiche Features" ins Spiel gebracht. Weil es mMn. keinen Sinn macht LOC Zahlen von Codes zu vergleichen die nicht wenigstens inetwa gleich robust sind bzw. die gleichen Fälle abdecken. Bzw. die gleichen funktionalen und nicht-funktionalen Anforderungen erfüllen (Thema "leicht änderbar mit wenig geänderten LOC" usw.).

Also ja: der Code da oben wäre mir auch "zu kurz". Findet man erfahrungsgemäss aber wie schon gesagt viel viel seltener als zu langen Code. Ist aber natürlich fast gleich schlimm.