Wieviel LOC pro Tag?

Xin

Mechanics schrieb:

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.

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. Die meisten Bugs, die ich "verschuldet" habe, bekomme ich deswegen, weil jemand ungefragt unfertige Software von mir abgreift und Features als fehlerhaft beschreibt, die ich noch gar nicht geschrieben habe. Da könnte ich auch 'nen Hals bekommen...

Debugging ist interessant und kann auch eine ganz neue Form von Kreativität bedeuten, aber ich muss auch klar sagen, dass ich den Job zur 3D-Visualisierung angenommen habe, weil ich mal wieder sehen wollte, was ich programmiere. Ich mache sonst Compilerbau und wenn Du zwei Wochen Zeit investiert hast, der Compiler fehlerfrei läuft und nichts meldet, dann ist das... ähh... ein tolles Erlebnis, aber

> gsys testprogramm.g
>

schaffen andere mit in wenigen Sekunden mit einem int main() {}. Du weißt, was da intern alles passiert ist, aber man kann es nicht mal jemandem zeigen, der keine Ahnung davon hat.

Ich war mal bei meinem neuem Chef und erklärte ihm, dass ich Low-Level-Programmierung mache. Danach musste ich ihn davon überzeugen, dass Low-Level nicht bedeutet, dass ich unfähig bin, weil auf geistig niedrigem Niveau arbeite, sondern eben die Grundlagen beschreibt auf dem alles andere aufbaut.
Das Problem hat unser GUI-Praktikant nicht. Der leistet ja was - sieht man doch, der macht viele tolle neue Dialoge, die man dem Kunden präsentieren kann.

Andere Programmierer lösen Probleme. Die Testbeispiele laufen, das sieht cool aus. Dann gibt's Applaus, dann kommen die Anwender, die ihre Probleme mit der Software lösen wollen. Dann haben wir einen Bug und der Entwickler gerade keine Zeit.
Wenn ich dann die halbverstandene, unkommentierte Lösung des anderen Entwickler nachvollziehe, dann das Problem des Kunden nachvollziehe und feststelle, dass das die Lösung leider nicht zum Problem passt, werfe ich diese weg und schreibe eine allgemein passende Lösung. Der erste Entwickler hat das Problem in 2 Tagen gelöst und ich habe einen kleinen Fehler in 2 Wochen behoben. In der Wirkung kann die Software jetzt nicht mehr als vorher, nur dass das Beispiel vom Kunden jetzt auch funktioniert und nicht nur die Testbeispiele.
Wenn man dann noch hört, dass die vorherige Lösung "aus dem Internet inspiriert" war, also auch nicht wirklich nachvollzogen wurde, sondern nur lauffähig gemacht wurde, dann nervt das schon etwas, weil der Kollege hat seine Show gehabt und ich habe ja nur einen kleinen Fehler für den Kunden behoben.

Debugging macht schon Spaß, aber gelegentlich will man auch sehen und zeigen, was man erschaffen hat. Und das funktioniert mit Debugging leider nicht.

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden. Und es ist einfach geiler, wenn man ein neues Feature sieht als wenn man für ein bereits verbuchtes Feature einen Bugfix macht.

MfG schrieb:

so sehe ich das auch, manchmal ist es auch mit einem enormen wissenszuwachs verbunden, solche fehler überhaupt erst einmal zu identifizieren...

Als ich C und C++-Tutor war, habe ich den Leuten immer wieder Aufgaben gegeben, bei denen sie mit Sicherheit in gemeine Fehler laufen und lies sie dann debuggen, Fragen stellen, nachvollziehen, was passiert und ihre Erwartungen zu formulieren und zu gucken, warum was passiert nicht ihren Erwartungen entspricht.

Ich habe den Leuten nicht beigebracht, wie man es richtig macht, sondern wie man es nicht falsch macht. Und dafür mussten sie es halt erstmal falsch machen, um dann zu lernen, warum das ihr Fehler nicht funktioniert.

Mit der Zeit fingen sie an, vor dem Tippen nachzudenken, wo sie in Fehler laufen können, denn irgendwann hatten sie raus, dass alle meine Aufgaben gemein sind. Da ich sie immer mit Ankündigung dumm dastehen lies, wollten sie mir ja zeigen, dass sie kleverer sind als meine Aufgabenstellungen. ^^

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Xin

Loading schrieb:

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Vermeiden, nicht verzichten - soweit bin ich dann doch noch nicht.

Debuggen vermeiden bedeutet Fehler vermeiden.
Und Fehler vermeiden bedeutet die Sprache voll auszunutzen: Const-Correctness, Templates, Mehrfachvererbung, viele bezeichnende Datentypen. Auch mal Zeit investieren, um einen neuen Datentyp (z.B. class Position) aus einem alten (unsigned int Position) herauszuholen, wenn man ihn häufiger braucht, statt hier und da ein paar ints reinzustreuen.
Und nachdenken, bevor man was tippt. Oder das tippen eben sein lassen, wenn man merkt, dass man nur Matsch in der Birne hat und in der Zeit halt eher Quelltext aufräumen und kommentieren, statt Fehler einbauen. Oder Tests schreiben. Jedenfalls nichts komplexes tun, was noch komplexer zu debuggen ist, falls es schief geht.

Es geht vorrangig darum, nicht den richtigen Zeitpunkt für eine Aufgabe zu verpassen, bzw. umgekehrt eine Aufgabe nicht zum falschen Zeitpunkt zu beginnen.

Gregor

Xin schrieb:

Und Fehler vermeiden bedeutet die Sprache voll auszunutzen

Unter Umständen kann es aber auch bedeuten, bewusst auf bestimmte Sprachmittel und Herangehensweisen, zu denen eine Sprache einlädt, zu verzichten.

volkard

Xin

volkard schrieb:

Loading schrieb:

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Naja…

(Achtung, ich schweife persönlich ab. Bitte nicht lesen, wenn Dir die Zeit kostbar ist.)
...
Klar hatte ich damit Phasen, wo ich 8 Wochen Vollzeit nach einem Fehler suchte.

Am Anfang dachte ich, hier kommt etwas Interessantes, aber das wird ja wohl ein Frontalangriff.

volkard schrieb:

Wenn ein Vollprofi erreichbar war, frugte ich ihn und er sagte "schau mal nach malloc und ob die Zeilen drunter echt passen" und pardauz, er hatte recht! Die Halbprofis aber haben immer nur zurückgefragt "Was willste denn machen?" und so. Aber arschgeleckt, ich kann ihnen doch nicht meine genialen nobellpreiswürdigen Plan verraten. Wie lockt man Vollprofis in sein Fänge, die einem längst nicht mehr helfen wollen? Zur Not organisiert man eine Party und wenn er schonmal da ist…
Er schaut sich den Ausdruck an, er sagt das bekannte "schau mal nach malloc und ob die Zeilen drunter echt passen" und pardauz, er hatte recht!

Sorry, der Fehler hatte nichts mit malloc zu tun.

volkard schrieb:

Das Debuggen ist mit MSVC eine Wonne! Als der MSVC6 rauskam, hing ich nur am Debugger.

Ich habe mich MSVC 6 immer verweigert bis 2012. Da musste ich ein Programm von MSVC6 nach 2010 portieren.

volkard schrieb:

Das mache ich kaum noch, hab Jahre ohne quasi Debugger gelebt. MinGW unter Win und der Debugger GDB lief nur als Admin oder so. Bei arger Verwirrung mal Codefragmente im MSVC debugt.

gdb läuft auch unter meinem Account, ich programmiere privat hauptsächlich unter Linux, nutze aber tatsächlich gelegentlich aber auch MSVC zum Debuggen.

volkard schrieb:

C++ ist total der Hammer, was es angeht, den Compiler dazu zu bringen, Leichtsinnsfehler zu Compilerfehlern zu machen!

Unter MSVC gibt's genug Compilerfehler, bevor man Leichtsinnig sein kann
Dann steht da aber auch "Interner Fehler" oder das Studio fliegt einem gleich um die Ohren. Das müssen Leichtsinnsfehler sein.

volkard schrieb:

Vielleicht auch die Tatsache, daß ich trotz viel~(mehr als viel, aber gibt keine Worte, die das ausdrücken)~ Computerbegeisterung keinen 64-er bekam, aber die meisten Freunde einen hatten.

Ich habe meinen C64 drei Wochen nach meinem 10. Geburtstag gekauft, lange bevor Freunde einen Computer und auch vor den meisten Eltern.

volkard schrieb:

Hab daheim auf Papier programmiert

Stimmt. Der Assemblerkurs war auf der Rückseite mehrerer MagicDisk-64-Disketten und mangels Multitasking oder Multi-C64er konnte ich entweder lesen oder programmieren, aber nicht beides.
Also Papier, dann abtippen, dann testen. Und debuggen war damals nachdenken, wenn der Computer sich aufgehängt hat.
Das war später, als ich Asm auf dem Amiga schrieb nicht anders. Und das hat mir auch beigebracht, dass denken schneller als debuggen geht, weil man mit Denken Debuggen vermeiden kann.

volkard schrieb:

Nuja, den Debugger verwende ich derzeit auch nicht. Gelegentlich, wenn was nicht stimmt, eine Debug-Ausgabe (hab alle Makros und Klassen und templates dahingehend weggeworfen, zu selten benutzt) und dann sehe ich den Fehler.

Debugger benutze ich, aber tatsächlich reichen mir meistens ein paar printf.

volkard schrieb:

Sonstnochwas? Joo, ich bin ja auch in der Lehre unterwegs. Da fragt mich ein Seminarteilnehmer nach einem Fehler und ich springe hin. Ja, ich eile hin trotz meiner rundlichen Figur, anstatt am Pult zu bleiben und seinen Moni einzublenden, weil ich durch das freudige Anhüpfen auf Fehlersuche den Leuten ganz tief reingebe, daß sie mir voll einen Gefallen tun, wenn sie bei einem Problem nachfragen.

Ich bin nicht mehr Tutor. Ich habe es tatsächlich in die freie Wirtschaft geschafft.
Trotz meiner rundlichen Figur bin ich tatsächlich zu den Monitoren gegangen. Nicht nur, weil es keine Infrastruktur gab, um den Monitor bei mir einzublenden, zum anderen, weil es kein "bei mir" gab. Ich habe keinen Computer benutzt, sondern die Tafel.

volkard schrieb:

Dadurch habe ich auch bei denen einen Zugang, die zu höflich sind, mal nachzufragen. Und ich sehe den ganz kleinen Fehler im ansonsten richtigen Code aus 5m Entfernung, sage ihn und kullere zurück. Dann denken die, ich wäre schlau.

Teilweise musste ich nichtmal hinkullern, sondern kannte den Fehler ohne auf den Monitor zu sehen. Dann dachten die wirklich, ich wäre schlau.
Und nein, es war nicht malloc.

volkard schrieb:

Das ist hilfreich, dann nehmen sie meine Ratschläge für die Zukunft (kleine Funktionen bauen, Variablen lokal machen und so) auch eher an. In Wirklichkeit sind die Schüler vergleichsweise viel schlauer, ich hab den Fehler selber hundertmal und mehr gemacht, nur deswegen sehe ich ihn schnell.

Stimmt. Ich habe programmieren aus Fehlern gelernt. Ich programmiere seitdem ich 9 bin und der Bücherpreis war leider viele Jahre nicht taschengeldkompatibel und mein Vater sah in dem Spielzeug "Computer" keine Zukunft. Jedenfalls hat er mir nie ein Buch dazu gekauft und wenn ich Geld hatte, ging das für Hardware drauf.
Also habe ich Spaghetti-Code in Basic geschrieben, lange Funktionen in C benutzt und globale Variablen in so ziemlich jeder Sprache.
Und daraus gelernt.

volkard schrieb:

Zurück zum Thema. Popelcode kann ich fehlerfrei liefern. GUI-Klassen anwenden. Datenbankabfragen. *langweil*. Und so Sachen, die mir Spaß machen, Bäume, verkettete Ringe, verschiedene Hashtables, einfache Numerik, Bitgefummle…
Daß ich fast gar nicht debugge, liegt nicht daran, daß ich so schlau wäre, denn das bin ich gar nicht.

Hier liegst du auch richtig. Ich habe lediglich vieles schon oft gemacht und damit kenne ich die meisten Standardprobleme. Darum habe ich vielleicht auch nicht so die Probleme mit malloc.

volkard schrieb:

Ich bin höchstens ein wenig anders. Es liegt daran, daß meine Anforderungen stehengeblieben sind.

Das wiederum stimmt nicht. Denn viele Probleme benötigen viel Popelcode. Wirklich interessante Sachen sind nunmal kein Massenmarkt und in der Wirtschaft muss man was verkaufen.
Und auch im Low-Level-Bereich ist das Programmieren halt auch oft if und while und Funktionen, wo man lieber lokale als globale Variablen nimmt.

volkard schrieb:

Sorry, mir war danach. Danke der Tradition dieses Forums, daß man recht frei abschweifen darf.

Jow... Du hast mal wieder festgestellt, dass Du Mr. Allwissend bist und ich nichtmal ein Halbprofi. Wobei ich vermutlich einfach nur anders arbeite als Du. Im Prinzip weiß ich nichtmals ob Du überhaupt was machst - also außer rumzustänkern. Von daher... was interessiert mich, was Du feststellst?

Wenn Du was Interessantes oder Hilfreiches aus deiner Erfahrung gepostet hättest, was Dein Ego ein wenig begründen würde... ist mir bei Dir aber nicht nur in diesem Posting nicht wirklich aufgefallen. Kommt ja vielleicht noch...

@volkard, xin:
Ihr solltet mal ein Buch schreiben "C++ im Alltag" oder so. Bücher die den Syntax und die Standardlib + Tricks und Rezepte runter beten gibt es genug, aber Bücher die so kleine Projekte von A-Z mit allem drumherum und ein wenig Geschichte dazu erzählen gibt es meines Wissen gar nicht.

Noch eine Frage, wenn ihr kaum debuggt, dann macht ihr auch kaum logische Fehler?

Ich, als Anfänger, tappe von einem Fettnäpfchen ins nächste. Ich verbringe mehr Zeit auf Seiten wie StackOverflow, in Büchern, Tuts, Videos über C++, mit Notizen machen, als in der IDE selbst. Naja, mit 42 lernt man auch nicht mehr so leicht, wie damals ASM auf dem Amiga.

SeppJ

Citizen42 schrieb:

Noch eine Frage, wenn ihr kaum debuggt, dann macht ihr auch kaum logische Fehler?

Ja, die kleinen Fallen, in die man als Anfaenger oefters rein rennt, kennt man nach einer Weile alle. Ebenso kennt man gute, bewaehrte Loesungen fuer die ganzen kleinen Teilprobleme, denen man immer wieder mal begegnet. Selbst wenn man hier mal einen Fluechtigkeitsfehler macht, dann findet man ihn schnell auch ohne Debugger, weil man es schon so oft gemacht hat und die typischen Fehler und Symptome kennt. (Und auch sehr wichtig ist das, was volkard gesagt hat, dass man in C++ den Compiler sehr gut abrichten kann, Logikfehler zu entdecken. Das geht aber so ziemlich nur in C++ und kaum einer anderen Sprache. Ist einer der Gruende, warum ich die Sprache so mag. Kaum eine Chance fuer Fluechtigkeitsfehler^*)

Bei den grossen Problemen macht man hingegen keine Logikfehler, weil man da normalerweise nicht mit einer "mal ausprobieren ob das funktioniert"-Einstellung rangeht, sondern sich vorher genau ueberlegt, ob und wie das Problem zu loesen ist. Oder wenn man doch einfach drauf los programmiert (ich mache das gerne, weil ich eine Gefuehl dafuer habe, wie die Loesung aussieht und die Details beim Programmieren kommen) und in dabei in eine Sackgasse laeuft, dann braucht man auch keinen Debugger, da man ja gar nicht bei einem fehlerhaften Programm angekommen ist.

^*: Das geht aber auch nur, wenn man es richtig macht. C++ kan man auch sehr falsch benutzen und dann wird Fehlersuche schwer. Das sind dann die Leute, die sich hier im Forum beschweren, was das fuer eine dumme, primitive Sprache waere.

tntnet

Citizen42 schrieb:

Ich, als Anfänger, tappe von einem Fettnäpfchen ins nächste. Ich verbringe mehr Zeit auf Seiten wie StackOverflow, in Büchern, Tuts, Videos über C++, mit Notizen machen, als in der IDE selbst. Naja, mit 42 lernt man auch nicht mehr so leicht, wie damals ASM auf dem Amiga.

Das ist schon eine sehr gute Art, C++ zu lernen. Die Fettnäpfchen werden mit der Zeit immer weniger und man lernt, neue Fettnäpfchen zu analysieren und frühzeitig zu erkennen.

Ich kann SeppJ nur zustimmen, dass C++ einen sehr gut unterstützt, wenn man damit umgehen kann. Es gibt aber keine Abkürzung an den Fettnäpfchen vorbei. Also nur Mut. Es lohnt sich .

Das macht mir Mut, danke. Ich lerne mit dem Buch "Einführung in die Programmiersprache mit C++" von Bjarne Stroustrup und natürlich ganz viel vom selbst ausprobieren. Aber bis jetzt konnte ich jedes Problem mit Hilfe von Google lösen. Es ist ein enormer Vorteil solch eine Riesen-Community hinter einer Sprache zu haben und seien wir mal ehrlich, die meisten Programme, die wir so nutzen, sind doch in C++ geschrieben, oder? Und sobald es auf den Smartphones und Tablets mal etwas performant werden soll, dann wird ja wohl auch nur ausschließlich mit C++ und ObjC gearbeitet, aber das ist nur eine Vermutung von mir.

Und Java, es tut mir Leid das sagen zu müssen, ist in meinen Augen auch nicht die richtige Sprache um das Programmieren zu lernen, da eben viele Aspekte des Programmierens eines Computers vor dem Anwender versteckt werden. Zumal ich Java nach wie vor lahm finde. Ich habe mal ein paar Stunden mit dem neue SceneBuilder eine GUI zusammen geklickt und das Programm wurde nach neun Textfelder, ein paar Labels und Layoutmanager richtig langsam und das auf einem neuen i7-Desktop + dicker GPU!

Na gut, reden wir hier nicht über Java, für irgendwas wird das schon gut sein.

Gregor

Citizen42 schrieb:

Und Java, es tut mir Leid das sagen zu müssen, ist in meinen Augen auch nicht die richtige Sprache um das Programmieren zu lernen, da eben viele Aspekte des Programmierens eines Computers vor dem Anwender versteckt werden.

Ich weiss nicht, warum Du hier ploetzlich Java thematisierst, aber mit der Argumentation, die Du da zum Besten gibst, solltest Du das Programmieren mit Assembler lernen.

Das habe ich sogar früher mal auf dem Amiga und auch jetzt werde ich dahin gehend mal einige Versuche auf dem PC unternehmen. Aber eine Hochsprache ist da dann doch schon komfortabler und ich traue den Compilern auch schönen Maschinencode zu, aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000. Ich weiß nicht wie der x86 Assembler so ist, aber da werde ich mich auch noch mit beschäftigen.

Gregor

Citizen42 schrieb:

Das habe ich sogar früher mal auf dem Amiga und auch jetzt werde ich dahin gehend mal einige Versuche auf dem PC unternehmen. Aber eine Hochsprache ist da dann doch schon komfortabler und ich traue den Compilern auch schönen Maschinencode zu, aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000. Ich weiß nicht wie der x86 Assembler so ist, aber da werde ich mich auch noch mit beschäftigen.

Das war von mir nicht wirklich ernst gemeint. Natuerlich bist Du mit Assembler naeher an der eigentlichen Maschine dran, aber Programmieren hat nicht nur etwas mit einem Low-Level Verstaendnis eines Computers zu tun. Jenseits davon lernst Du das selbst mit Assembler nicht wirklich. Natuerlich lernst Du mit Assembler, was zum Beispiel Register sind, Aber mit Dingen wie Pipelining, der Speicherhierarchie und so weiter kriegst Du es auch nicht direkt zu tun. Wenn Du fuer Deine Programmiertaetigkeit ein solches Verstaendnis von Computern benoetigst, dann solltest Du neben dem Erlernen der Programmiersprache ein Buch wie zum Beispiel das da durcharbeiten:
Computer Architecture | ISBN: 012383872X

Danke für den Buchtipp. Benötigen tue ich solches Wissen nicht. Das ist wie früher beim Democoding(nix bekanntes) auf dem Amiga einfach nur Hobbykram. Assembler war halt die einzige Sprache, mit der ich wirklich was mit dem Computer machen konnte. C + Libs waren damals grottenlahm und Basic naja nochmal hundert Stufen lahmer. Mir ist schon klar, dass das heute alles anders ist mit Multicore, der Pipeline und den Caches. Damals war Assembler halt nichts besonderes. Das haben eigentlich alle programmiert und es wurden auch viele Bücher und Artikel in Zeitschriften darüber geschrieben. Internet gab es ja nicht, also musste man selbst die Fehler finden. Schwer war das damals überhaupt nicht, wenn man einmal den Dreh raus hatte. Waren ja auch nur sehr wenige Befehle mit sehr wenigen Fragezeichen. Man musste halt geschickt auf die Register aufteilen und den Rest auf den Stack packen. Die Customchips kennen und wissen wie man die ansteuert, musste man auch, aber so viele waren das ja auch nicht. Und das schöne daran, so gut wie jeder hatte dieselbe Hardware, es gab einfach nie irgendwelche Sonderfälle zu beachten.

Aber ich gerate schon wieder ins Schwärmen, wie einfach das alles damals war. Aber nun probieren ich es mal mit C++ und OOP, an das ich mich erst noch gewöhnen muss, es sind aber tolle Pattern dafür vorhanden, wirklich beeindruckend.

Also alles nur ein Versuch eines alten Mannes mal wieder etwas zu programmieren, mehr nicht, reines Hobby.

Citizen42 schrieb:

aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000.

und der auf dem 800386 erstmal

Xin

Citizen42 schrieb:

@volkard, xin:
Ihr solltet mal ein Buch schreiben "C++ im Alltag" oder so.

Das hat SeppJ in seinem letzten Posting schon. Es ist wirklich Handarbeit, Erfahrung sammeln.
Ich habe 1996 mit C++ angefangen, davor C, davor Assembler. Insgesamt programmiere ich fast seit 30 Jahren. Wie ich schon volkards Geschichte korrigierte, ich habe vorrangig aus Fehlern gelernt und wenn man ein paar Stunden über Assemblerquellcode gehangen hat, um herauszufinden, warum gelegentlich der Computer abschmiert, dann versteht man Abläufe irgendwann schnell bzw. entwickelt da wirklich ein Gefühl für, wo man mehr überlegen muss und was einem einfach so aus den Fingern in die Tastatur fließt, weil man das immer so macht.

Citizen42 schrieb:

Bücher die den Syntax und die Standardlib + Tricks und Rezepte runter beten gibt es genug, aber Bücher die so kleine Projekte von A-Z mit allem drumherum und ein wenig Geschichte dazu erzählen gibt es meines Wissen gar nicht.

Die Geschichte ist oftmals sehr frustrierend.

Citizen42 schrieb:

Noch eine Frage, wenn ihr kaum debuggt, dann macht ihr auch kaum logische Fehler?

Das würde ich so nicht sagen. Ich mache auch seit 10 Jahren regelmäßig alle 2 Jahre folgenden Anfänger-Fehler:

if( cond1 ) 
  if( cond2 ) OneAndTwo();
else NotOne();

Man startet das Programm, es funktioniert nicht, man sieht den Code, haut sich auf die Stirn, und korrigiert es:

if( !cond1 ) 
  NotOne();
else if( cond2 ) 
  OneAndTwo();

Oftmals sieht man die Ausgabe und weiß, warum kommt, was kommt, weil damit das kommt, was ausgegeben wird, muss der Fehler da und da liegen. Und dann guckt man an die Stelle und meistens sieht man schnell, wo sich der Algorithmus verläuft, um das Ergebnis zu liefern, dass man halt bekommen hat.
Man testet das ganze ja, weiß also was man reingibt und wie der zu testende Algorithmus daraus ein Ergebnis formen soll, was dann aber halt nicht kommt.

Das sehe ich aber nicht als "Debuggen", das ist Alltag beim Entwickeln.

Debuggen fängt bei mir da an, wo man lange sucht, bzw. wo man einen Quellcode in die Versionsverwaltung entlassen hat und ein Kunde oder anderer Entwickler in einen freigegebenen Quellcode Fehler findet.

Manchmal sitzt man auch einfach vor einem Quellcode und findet ihn "nicht schön". Das ist oft erstmal mehr ein Gefühl, aber dann guckt man sich das genau an und merkt, dass das besser geht. Es ist einfach nicht so, wie man das als "schön" empfindet, wie man das immer macht, weil man weiß dass der "schöne" Quellcode in allen Fällen funktioniert.

Programmieren ist oftmals das richtige Zusammenstellen von Legobausteinen, also Code-Schnipseln. Und je länger man programmiert, desto mehr "schöne" Codeschnipsel kennt man und umso größer werden sie.
Es ist halt Erfahrung.

Citizen42 schrieb:

Ich, als Anfänger, tappe von einem Fettnäpfchen ins nächste. Ich verbringe mehr Zeit auf Seiten wie StackOverflow, in Büchern, Tuts...

Dann machst Du es genau richtig. Der Rest ist "einfach" nur Erfahrung: Handarbeit.

Citizen42 schrieb:

Und Java, es tut mir Leid das sagen zu müssen, ist in meinen Augen auch nicht die richtige Sprache um das Programmieren zu lernen, da eben viele Aspekte des Programmierens eines Computers vor dem Anwender versteckt werden. Zumal ich Java nach wie vor lahm finde.

Java ist nicht unbedingt lahm, wenn das Problem groß genug ist und genug Speicher da ist. Java ist spezialisierter als C++. Wenn man also ein Problem hat, für das Java spezialisiert ist, sollte man sich durchaus mal mit C# beschäftigen
Ich halte C allerdings auch für besser, wenn es darum geht programmieren zu lernen.

https://www.proggen.org/doku.php?id=start:cppjava

Citizen42 schrieb:

aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000. Ich weiß nicht wie der x86 Assembler so ist, aber da werde ich mich auch noch mit beschäftigen.

Warum nicht... aber wenn man einen 68000er programmiert hat, dann ist ein Intel schon eine traurige Nummer, was die Programmierung angeht.

EOP

volkard schrieb:

Mit 30 biste gut dabei.

Ist nicht dein Ernst - wenn das so ist dann steige ich auch wieder in das Berufsleben ein.

Xin

EOP schrieb:

volkard schrieb:

Mit 30 biste gut dabei.

Ist nicht dein Ernst - wenn das so ist dann steige ich auch wieder in das Berufsleben ein.

Üblicherweise wird mit 10 LOC pro Arbeitstag gerechnet. Mit 30 ist man wirklich ziemlich gut dabei.

SeppJ

Xin schrieb:

Das würde ich so nicht sagen. Ich mache auch seit 10 Jahren regelmäßig alle 2 Jahre folgenden Anfänger-Fehler:
if( cond1 ) 
  if( cond2 ) OneAndTwo();
else NotOne();

Du glaubst nicht, wie viele Fehler dieser Art ich schon direkt während des Fehlermachens gefunden habe, einfach weil mein Editor automatisch den Code einrückt. So ein Gerät sollte Pflicht sein.
Auch beliebt und durch gutes Arbeitsgerät direkt vermeidbar sind einfache Tippfehler. Semikolon vergessen, Klammern passen nicht, und so weiter. Vielleicht gehört in jedes Programmieranfängerlehrbuch ein Kapitel über gängige Editoren und wie man sie produktiv einsetzt. Das sieht man ja schon hier im Forum, wie viele Beiträge von Anfängern man direkt beantworten kann, indem man ihren Code einfach mal von einem Editor automatisch einrücken lässt.
Und ein Kapitel über gängige Compiler (oder Compiler/IDE-Gespanne) und wie man Warnungen aktiviert.

Ich glaube kaum etwas anderes hat meine Produktivität so sehr gesteigert, wie ein guter Editor und Compilerwarnungen. Denn auch wenn man als erfahrener Programmierer all diese Fehler kennt und bei der Fehlersuche sofort sieht, so macht man sie doch trotzdem immer mal wieder versehentlich. Es bringt so viel, wenn die Notwendigkeit, diese Arten von Fehlern zu suchen, gänzlich entfällt.

Xin

SeppJ schrieb:

Xin schrieb:
Das würde ich so nicht sagen. Ich mache auch seit 10 Jahren regelmäßig alle 2 Jahre folgenden Anfänger-Fehler:
if( cond1 ) 
  if( cond2 ) OneAndTwo();
else NotOne();
Du glaubst nicht, wie viele Fehler dieser Art ich schon direkt während des Fehlermachens gefunden habe, einfach weil mein Editor automatisch den Code einrückt. So ein Gerät sollte Pflicht sein.

Das ist die eine Perspektive. Ich arbeite mit Visual Studio, CodeBlocks, CodeLite, Kate und TextWrangler. Letztere sind eigentlich eher nur Editoren.
Die Programmierung mit einfachen Editoren hilft mir Methodennamen zu optimieren. Nachschlagen kostet Zeit; um Zeit zu sparen, achte ich darauf, Methodennamen zu vereinheitlichen. Wenn ich nachschlagen muss, ist der Methodenname fraglich.

Keiner formatiert meinen Code oder rückt ihn ein. Das tat Eclipse. Ich habe es gehasst, wenn ich meinen Code optisch ausgerichtet habe, so dass Ähnlichkeiten sofort ins Auge fielen und der Code dann automatisch so angepasst wurde, dass man den Algorithmus aus der Formatierung nicht mehr lesen konnte.

Ich verzichte auf Diskussionen mit meinem Computer, wann mein Code richtig formatiert ist. Ich hasse es, wenn mein Computer besser wissen will, was ich tun will. Ich hasse auch Autokorrektur, weil es aus einem Tippfehler ein komplett anderes Wort macht - ich also noch mehr korrigieren muss. Computer sollten nicht intelligenter tun, als sie sind.

Den beschriebenen Fehler mache ich zuverlässig alle 2 Jahre mal, er kostet mich in der Regel kaum mehr als 5 Minuten, weil ich ihn sofort sehe, wenn ich nach Fehlern suche und den fraglichen Code überfliege. Dieses fehlerhafte Konstrukt programmiere ich nicht, sondern es entsteht, wenn ich einen solchen Block ändere und dabei abgelenkt werde.

SeppJ schrieb:

Auch beliebt und durch gutes Arbeitsgerät direkt vermeidbar sind einfache Tippfehler. Semikolon vergessen, Klammern passen nicht, und so weiter.

Fehler, die man nicht kompilieren kann sind ja Kleinkram.
Darum liebe ich Const-Correctness: Man kann es nicht kompilieren, wenn man nicht sauber arbeitet.

SeppJ schrieb:

Und ein Kapitel über gängige Compiler (oder Compiler/IDE-Gespanne) und wie man Warnungen aktiviert.

Das entspricht so auch meiner Erfahrung und deswegen gibt's das bei uns auch.

SeppJ schrieb:

Ich glaube kaum etwas anderes hat meine Produktivität so sehr gesteigert, wie ein guter Editor und Compilerwarnungen.

Ich habe auf dem SAS/C mit C angefangen. Der Compiler hatte so gute Fehlermeldungen, dass ich mich oft genug gefragt habe, warum er den Fehler nicht gleich selbst behebt.
Gute Fehlermeldungen sind also möglich.
Viele lernen mit Visual Studio. Visual C++ liefert gelegentlich Fehlermeldungen, die ich selbst nach der Lektüre der Hilfsseiten von Microsoft nicht verstehe und die Fehlermeldung auch nicht nachvollziehen kann, wenn ich den Fehler gefunden habe.

SeppJ schrieb:

Denn auch wenn man als erfahrener Programmierer all diese Fehler kennt und bei der Fehlersuche sofort sieht, so macht man sie doch trotzdem immer mal wieder versehentlich. Es bringt so viel, wenn die Notwendigkeit, diese Arten von Fehlern zu suchen, gänzlich entfällt.

Ich klicke meistens nur auf die Zeile und gucke mir die Codestelle an. Das geht schneller, als die Fehlermeldung zu lesen. In 95% der Fälle reicht mir das.