Wie viel Zeilen programmiert ein C++ Programmierer am Tag? [was: Frage:)]
-
*lol* Puppet, ohne Scheiß?
Naja, da gebe ich den Unternehmen recht.
Die KostenProZeile sind in Deutschland viel zu hoch!
Quellcode muss wieder bezahlbar werden
Kein Geld für Whitespaces.lololololol
-
Ich schreibe auch viel mehr als am Ende übrig bleibt. Wenn ich mir ausreichend Gedanken über ein Projekt gemacht habe schreibe ich eine recht brauchbare Fassung über einen gewissen Zeitraum runter. Wenn die steht werden Feinheiten gemacht und Sachen eleganter gestaltet die mir nicht gefallen. An manchen Tagen schmeiße ich sogar mehr Code weg als ich schreibe, weil mir einfach eine gute Idee gekommen ist.
-
SeppSchrot schrieb:
Kein Geld für Whitespaces.
YARR!!!!
Objectfiles bitte beitseitig benutzen, Compilerlaeufe sind teuer o_0Wenns wirklich noch jemand interessiert: bei mir sinds wenn ich richtig top-mega-motiviert bin evtl. auchmal 1.000 Zeilen/Tag. Wieviel davon aber die erste Debugging-Session ueberstehen steht auf 'nem anderem Blatt.
-
PuppetMaster2k schrieb:
Hm Wie viele Zeilen ich schreibe ist unterschiedlich. Mal nur 2 oder 3, mal sinds dann eben 100 oder mehr. Zur Zeit ist das aber recht nervig, weil ich mir aufschreiben muss, wie viele Zeilen Code ich geschafft habe. Alles im Rahmen von Outsourcing-Maßnahmen und Preiskalkulierung... Das ist vielleicht ätzend!
OMFG, die Wirtschaftler schon wieder. Gott schütze uns vor denen!
-
Ich muss mir auf jeden Fall ne Festanstellung besorgen wenn ich das hier so lese werde ich ja direkt neidisch. :p
-
Habt ihr es mehr mit Kleinaufgaben und/oder Fehlerbehandlung zu tun, das heißt, ihr müsst sowieso nur 3 Zeilen Code an der richtigen Stelle einfügen bloß erstmal rausfinden wo und warum, oder seid ihr mehr für "Mach mal so ne Lib und sag mir wie ich sie anwenden kann - gut bin dabei"-Programmierer, die dann auch mal ein Monat für Quellcode Zeit haben und dann auch die Planungsphase größer ausfallen lassen?
MfG SideWinder
-
was für eine frage!!!
ich zw. 0 und > 0 und ich spreche nicht von hobbyprojekten.Nach Codezeilen bezahlt zu bekommen ist ja der hammer.
if() { machwas } else { machwas }8 Zeilen.
obwohl es auch mit 4 geht.
-
Projekte die zwei Jahre laufen und dann aber natürlich noch Jahre später gepflegt werden. Entwickler sind im Schnitt drei Leute, max. 12 Leute. Das sind die Projekte in denen ich arbeite.
Nach Sourcecode wurden wir noch NIE gefragt!!! Der Kunde hat eh keinen Plan davon, den interessiert auch nur das was er auf dem Bildschirm als Endanwender sieht und ob alles reibungslos in freier Wildbahn läuft.
Habe auch noch nie gehört, das man nach geschriebenen Code bezahlt wird.
-
SeppSchrot schrieb:
Naja, da gebe ich den Unternehmen recht.
Die KostenProZeile sind in Deutschland viel zu hoch!
Quellcode muss wieder bezahlbar werden
Kein Geld für Whitespaces.Das ist nicht wirklich lächerlich. An irgendetwas muss man ja versuchen sich kostenmäßig zu orientieren. Die Kosten grob abschätzen zu können und in gewissen Grenzen zu halten ist oft unabdingbar für den Erfolg eines Projekts. Viele Methoden zur Kostenabschätzung eines Projekts basieren auf der Zählung von LOC. Es gibt auch andere wie zb. Function Point die sich da eher mehr an den Projektanforderungen orientiert. Aber das Gebiet ist recht schwammig, sehr viele Einflussfaktoren das is auch das was es so schwierig macht.
Es gibt natürlich auch recht schwachsinnige Dinge wie zb. die Produktivität eines Programmierers anhand von LOC zu messen.
bye
tt
-
Naja aber was willst du denn für eine Kennzahl nehmen die im vornherein nicht vom Programmierer selber beeinflusst werden konnte? Wenn ich weiss dass ich nach Zeilen Quellcode bezahlt werde dann schreibe ich meinen Programmcode in so vielen Zeilen wie möglich. Wenn ich weiss dass ich nach der Summe der erstellten Funktionen und Methoden bezahlt werde dann lagere ich eben jeden Dreck in eine eigenständige Funktion um etc.
-
Pulse schrieb:
Naja aber was willst du denn für eine Kennzahl nehmen die im vornherein nicht vom Programmierer selber beeinflusst werden konnte? Wenn ich weiss dass ich nach Zeilen Quellcode bezahlt werde dann schreibe ich meinen Programmcode in so vielen Zeilen wie möglich. Wenn ich weiss dass ich nach der Summe der erstellten Funktionen und Methoden bezahlt werde dann lagere ich eben jeden Dreck in eine eigenständige Funktion um etc.
Und wenn die Bezahlung nach der Zeit, die du für die jeweiligen Klassen brauchst, kalkuliert wird? Das ist dann schon schwieriger weil du dich ja nicht zu lange daran aufhalten kannst (eigentlich nur so kurz wie möglich) denn irgendwann ist ja Abgabetermin und man muss ja an mehr als nur einer Klasse arbeiten.
-
Wenn man nach Zeilen bezahlt wird, wie läuft das denn dann mit der Bezahlung beim fixen?
Wenn ich den einen Monat, sagen wir mal 1.000 Zeilen schreibe, welche ich dann ja auch entsprechend bezahlt bekomme, im nächsten Monat muss ich aber ein paar Dinge fixen und dann bleiben nur noch 800 Zeilen übrig, muss ich das Geld dann für die 200 Zeilen zurückzahlen und bekomme gar kein Geld für den Monat?
-
mantiz schrieb:
Wenn man nach Zeilen bezahlt wird, wie läuft das denn dann mit der Bezahlung beim fixen?
Ich glaube, das mit der Bezahlung nach Zeilen ist eine UL. Obwohl, wenn man sich die Einträge bei thedailywtf.com so anschaut...
-
nach zeilen bezahlt zu werden ist doch ne feine sache.
alleine durch den iostream-include klingelt die kasse schonmal recht ordentlich.
das was da drin steht, erhält der kunde doch schließlich auch.
und das kommentieren macht dann auch wieder
/*s
p
a
s
s
*/
-
wenn ich das so lese bin ja im guten mittelmaß schaffe pro tag zwischen 4-60zeilen
und ich dachte schon ich sollts mal lieber lassen wenns so langsam vorwärts geht
aber wenn ich das so lese von Termite dann bin ich echt fro das ich allein an meion projekt entwickle
denn mein verwaltungsaufwand besteht darin zu beginn ein script zu starten das mir meine tägliche arbeitskopie erstellt
und ein paar sachen startet
und meinen code dokumentiere ich auch immer nur mit sehr kleinen stichpunkten
ansonsten habe ich nur das programm ToDoList in dem ich fertige sachen abhacke bugs eintrage usw
bin damit vielleicht 10 min am tag beschäftigt die restlichen stunden sind bei mir meist suchen in diversen foren und webseiten nach ideen oder codebeispielen wie das angegangen wird oder hier auf die beantwortung meiner fragen warten
-
Die schönsten Tage sind die, wo der Code zu meinem Spiel um 50 Zeilen weniger geworden und das Spiel trotzdem noch genauso gut (oder besser) ist. Hab ich aber in letzter Zeit nicht mehr oft.
-
Optimizer schrieb:
Die schönsten Tage sind die, wo der Code zu meinem Spiel um 50 Zeilen weniger geworden und das Spiel trotzdem noch genauso gut (oder besser) ist. Hab ich aber in letzter Zeit nicht mehr oft.
Fang lieber nicht in einer Firma an, die nach Codezeilen bezahlt
-
Ich finde leider die Quelle nicht mehr, aber ich habe eine durchschnittliche Zahl von 30 Zeilen pro Tag im Kopf (gemittelt über viele Personen). Wobei Zeile hier halt CODEZEILE heißt, vielleicht sollte man es besser auch "Zeile die wo was tut" (ZDWWT statt LOC) bezeichnen. { und // zählt ergo nicht.
Zurück zur Zahl: ist im Mittel erschreckend gering. Aber normal! Denkt an Vorbereitung, Diskussionen, dann Dinge die man wegwirft (es zählt hier ja nur die zum Schluß noch vorhandene Zeile), die Testphase, Debugging... das zieht den Mittelwert ganz schön runter. Nur an wenigen Tagen wird man wirklich viele 1000 Zeilen einhacken. Aber um das zu leisten, hat man im Normalfall 2-3 Tage vorher 0 Zeilen gehabt, da man nur am denken war.
-
Ich programmiere ja nur hobbymäßig und daher mache ich alles nach lust und laune, aber was ich feststellen musste, ist dass ne Menge Zeit drauf geht, wenn man sich die Mühe macht jede Klasse zu dokumentieren, sei es in Kommentaren oder extra.
Wie macht ihr das denn? Einerseits will man ja für andere und für sich selbst dokumentiert haben, aber andererseits stört es (jedenfalls mich) auch, wenn man mal wieder ne Ewigkeit braucht für ne neue Klasse bevor man am eigentlichen Problem weiterarbeiten kann.
-
Ich dokumentiere nebenbei grob, eine vernünftige Doku mache ich dann, wenn ich grad irgendwo nicht weiter komme.