Wieviel LOC pro Tag?

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

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.

hustbaer

OT:

Ich hätte spontan mal das abgeliefert:

int words = 0;

char ch;
bool lastWasSpace = true;
while (ch = *str++)
{
    bool const isSpace = (ch == ' ');
    if (lastWasSpace && !isSpace)
        words++;
    lastWasSpace = isSpace;
}

Liesse sich mit ein Bisschen Getrixe vermutlich auch schnell machen.
Man könnte z.B. lastWasSpace und isSpace zusammen in z.B. einen int packen (in Bit 0 und Bit 1) und dann words += helperArray[dieserInt]; machen.
Aber dann wird's auch wieder unleserlich

EOP

Xin schrieb:

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

Kommentar ist falsch und irreführend

und jetzt kommt natürlich der Hammer um 03:18:

int main(int argc, char* argv[])
{
char *line = " aaa bbb  ccc  ";
int words = 0;

	words = isWord( line );
}

int isWord( char *line )
{
int ret = 0;
	while( *line && isspace( (int) *(line)++ ) );
	if( !(*line) )
		return( ret );
	while( *line && !isspace( (int) *(line)++ ) );
	ret = 1 ;
	ret += isWord( line );

return( ret );
}

EDIT:
Klappt nur leider nicht mit line = "a", ist mir jetzt aber auch zu spät, um da noch weiter rumzuspielen.

Keine Sorge, weiß schon, daß es daran liegt:

if( !(*line) )

Kannst du deinen Studenten mal vorlegen Xin und fragen warum es funktioniert und dann fragen, warum "a" nicht funktioniert.

hustbaer

OT

Hm.
Um das (Wörter Zählen) richtig schnell zu bekommen müsste man zu krummen Tricks greifen.

z.B. gucken ob es "safe" ist mehr als ein Byte zu lesen - wenn man nicht gerade an einer Page-Boundary ist kann man sich das ja leisten. Dann könnte man z.B. mit SIMD Befehlen 8 Byte auf einmal verwursten.

IIRC auch ein Standardtrick bei schnellen strlen() Implementierungen.

Xin

hustbaer schrieb:

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.

Nach gutem Code kommt Code, der krampfhaft bemüht ist, kurz zu sein ohne darauf zu achten, dass er gut ist.

Das Hauptziel ist allerdings maximale Geschwindigkeit. Es ging in erster Priorität nicht um schön zu sein, sondern um schnell.

hustbaer schrieb:

Liesse sich mit ein Bisschen Getrixe vermutlich auch schnell machen.
Man könnte z.B. lastWasSpace und isSpace zusammen in z.B. einen int packen (in Bit 0 und Bit 1) und dann words += helperArray[dieserInt]; machen.
Aber dann wird's auch wieder unleserlich

Und sehr, sehr langsam. ^^

EOP schrieb:

Xin schrieb:

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

Kommentar ist falsch und irreführend

Der Kommentar ist in meinen Augen absolut in Ordnung, weil er den Algorithmus und nicht den Quelltext beschreibt. *str ist ein Implementationsdetail, keine Problemlösung.

Edit: *stirnklatsch*

EOP schrieb:

und jetzt kommt natürlich der Hammer um 03:18:
int main(int argc, char* argv[])
{
char *line = " aaa bbb  ccc  ";
int words = 0;

	words = isWord( line );
}

int isWord( char *line )
{
int ret = 0;
	while( *line && isspace( (int) *(line)++ ) );
	if( !(*line) )
		return( ret );
	while( *line && !isspace( (int) *(line)++ ) );
	ret = 1 ;
	ret += isWord( line );

return( ret );
}
EDIT:
Klappt nur leider nicht mit line = "a", ist mir jetzt aber auch zu spät, um da noch weiter rumzuspielen.

Dein Code ist erstens gegen unsere Spielregeln (alles außer ' ' ist ein Wort), was ihn zum einen nicht vergleichbar machen würde und wenn wir ignorieren, dass er ein anderes Ergebnis liefern wird, wird er auch noch sehr langsam sein, weil Funktionsaufrufe (isspace und Rekursion) einfach nur teuer sind.
Warum definierst und initialisierst Du ret, nur um es zurück zu geben bzw. es zu überschreiben!? ret brauchst Du doch gar nicht!?

Ein Funktionsname ist ebenfalls ein Kommentar. Und "isWord" beschreibt nicht, was die Funktion leisten soll. Die Variable 'line' ergibt bei 'ispsace()' auch keinen Sinn, da ein Newline als Whitesapace erkennt.

Und da Du ja selbst schon gemerkt hast, dass es auch noch nicht funktioniert,

EOP schrieb:

Keine Sorge, weiß schon, daß es daran liegt:
if( !(*line) )
Kannst du deinen Studenten mal vorlegen Xin und fragen warum es funktioniert und dann fragen, warum "a" nicht funktioniert.

Ich mache derzeit keine Schulungen und Tutorien schon lange nicht mehr.

hustbaer schrieb:

Hm.
Um das (Wörter Zählen) richtig schnell zu bekommen müsste man zu krummen Tricks greifen.

Das ist das gemeine, dass man beim Wörterzählen noch auf das Leerzeichen prüfen muss. Falls hier noch was spannendes kommt, gucke ich nochmal, ob ich die Testsuite nochmal finde. ^^

Aber schon lustig, dass man hier so viele Leute noch mit einem scheinbar derart trivialen Problem durch die Nacht bringen kann.

volkard

Xin schrieb:

Aber schon lustig, dass man hier so viele Leute noch mit einem scheinbar derart trivialen Problem durch die Nacht bringen kann.

Hab zum Glück abgesachaltet, als Code von Dir kam.

Xin schrieb:

EOP schrieb:

Xin schrieb:

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

Kommentar ist falsch und irreführend

Der Kommentar ist in meinen Augen absolut in Ordnung, weil er den Algorithmus und nicht den Quelltext beschreibt. *str ist ein Implementationsdetail, keine Problemlösung.

Ich sehe auch nicht so direkt, daß der Code Leerzeichen überspringt. Hätte das Gegenteil geraten, wenn Du nocht so sicher wärst.

Xin

volkard schrieb:

Xin schrieb:

EOP schrieb:

Xin schrieb:

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

Kommentar ist falsch und irreführend

Der Kommentar ist in meinen Augen absolut in Ordnung, weil er den Algorithmus und nicht den Quelltext beschreibt. *str ist ein Implementationsdetail, keine Problemlösung.

Ich sehe auch nicht so direkt, daß der Code Leerzeichen überspringt. Hätte das Gegenteil geraten, wenn Du nocht so sicher wärst.

wtf... *lach*

Manchmal hat man echt Tomaten auf den Augen.

EOP

Xin schrieb:

volkard schrieb:

Xin schrieb:

EOP schrieb:

Xin schrieb:

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

Kommentar ist falsch und irreführend

Der Kommentar ist in meinen Augen absolut in Ordnung, weil er den Algorithmus und nicht den Quelltext beschreibt. *str ist ein Implementationsdetail, keine Problemlösung.

Ich sehe auch nicht so direkt, daß der Code Leerzeichen überspringt. Hätte das Gegenteil geraten, wenn Du nocht so sicher wärst.

wtf... *lach*

Manchmal hat man echt Tomaten auf den Augen.

Und mir fällt sowas nach 12 Bier um 3 morgens noch auf. :p

EDIT:
Und natürlich ein LOL @volkard.

hustbaer

Xin schrieb:

hustbaer schrieb:

Liesse sich mit ein Bisschen Getrixe vermutlich auch schnell machen.
Man könnte z.B. lastWasSpace und isSpace zusammen in z.B. einen int packen (in Bit 0 und Bit 1) und dann words += helperArray[dieserInt]; machen.
Aber dann wird's auch wieder unleserlich

Und sehr, sehr langsam. ^^

So wild ist das gar nicht.
So um die 30% langsamer als deine schnelle Variante.
Mit manuellem Loop-Unrolling (hab jetzt mal 7-fach probiert) dann auf x86 etwa gleich schnell und auf x64 etwa 20% schneller

Xin schrieb:

hustbaer schrieb:

Hm.
Um das (Wörter Zählen) richtig schnell zu bekommen müsste man zu krummen Tricks greifen.

Das ist das gemeine, dass man beim Wörterzählen noch auf das Leerzeichen prüfen muss. Falls hier noch was spannendes kommt, gucke ich nochmal, ob ich die Testsuite nochmal finde. ^^

Schon klar das mit den Leerzeichen.
Ich stelle mir vor:
Byte-fürByte Loop bis Alignment auf 8 Byte passt.
Dann 8 Byte in ein SIMD Register laden.
Dann gucken ob eins davon ne Null ist.
Dann vergleich mit Leerzeichen => Bitmaske draus machen.
Bitmaske in Register stopfen und das letzte Bit der vorigen Bitmaske dazu.
Damit nen Table-Loopup ( count += table[mask] ) => fertig. Für 8 Byte auf einmal braucht man nen Table mit 512 Einträgen. char reicht, also 512 Byte.
So lange wiederholen wie man keine Null findet.
Die letzten paar Byte dann wieder einzeln.
Das sollte ohne SIMD schon ein gutes Eck schneller sein als eine "Byte für Byte" Variante. Mit SIMD, wenn alle nötigen Befehle verfügbar sind noch viel schneller. (Parallel-Vergleichen gibt's, bin nur nicht sicher ob man das Ergebnis dann auch einfach in eine Bitmaske verwandeln kann.)

Dafür ist es halt kein portierbares C++ mehr, weil man ja offiziell nicht über die Grenzen eines Arrays bzw. einer Allokation hinauslesen darf. Sollte aber zuverlässig funktionieren, da das Alignment auf 8 Byte sicherstellt dass man zumindest keine Page angreift die man nicht hätte angreifen sollen. Und die Werte hinter der ersten Null werden auch nie wirklich ausgewertet, von daher sollte es auch Wurst sein dass man da Schrott liest oder diese Werte sogar von einer Race-Condition betroffen wären (wären, wenn man sie denn auswerten würde).

numLOC schrieb:

Guten Morgen,

ich arbeite bei einem große Mailanbieter und wir werden, unter anderem, danach bewertet wie viele Lines of Code wir pro Tag produzieren, das wird mit dem Versionskontrollsystem gemessen. Wie bei vielen Anbietern, wo die Mitarbeiter einem regen Wechsel unterzogen sind, ist der Code saumäßig schlecht und viele Köche haben da schon rumgerührt und selbst die Frameworks sind kaum updatebar, da Veränderungen daran von irgendjemanden mal vorgenommen wurden. Und für Ausbesserungen wird uns keine Zeit gegeben, da Featurausbau immer Vorrang hat.

Ich schaffe da manchmal nur 20-50 LOC pro Tag, da alles zudem noch extrem OOP ist und man wirklich kaum eine Chance hat da den Datenfluss noch nachzuvollziehen. Es existiert eine Doku, aber die wird auch mehr stiefmütterlich behandelt.

IBM hat auch nach KLOCs bezahlt und Steve Ballmer musste IBM klar machen, dass ein 4 KLOC Programm, das kleiner und schneller ist und das gleiche erreicht besser ist, als ein 10 KLOC oder 100 KLOC Programm:

http://youtu.be/PWylb_5IOw0?t=38m58s

KLOC steht für 1000 lines of Codes.