Gute Programmierbücher

[Baalzamon]

Nachdem mich mal wieder das große Zweifeln übermannt hat, ich schon seit ewigen Zeiten in meinem eigenen Saft brodel und ich keine Ahnung habe, ob der Code den ich so fabriziere auch nur im geringsten gut ist (whatever that means) bin ich zu der Erkenntnis gelangt, dass ich nach endlosen Jahren des vor mich hin Programmierens vielleicht doch mal ein Fachbuch zu dem Thema lesen sollte.

Mehrere Kandidaten springen mich an, wenn ich Google bemühe:

- Andrew Hunt, David Thomas: The Pragmatic Programmer
- Steve McConnell: Code Complete
- Robert C. Martin: Clean Code

Kennt die jemand von euch und kann was dazu sagen? Machen diese Bücher überhaupt noch Sinn, wenn man kein Programmieranfänger mehr ist?

Wie steht ihr eigentlich so dazu? Code aus der Hüfte schiessen? Vorher das Design total festlegen und dann nur noch runterprogrammieren?

[Mosher]

Ich halte relativ wenig von Büchern zum Programmieren allgemein (Außer vielleicht als Anfänger)

Für bestimmte Sprachen oder Plattformen kaufe ich hin und wieder einen Wälzer zum Einsteigen und Nachschlagen, die meiste Information hole ich mir allerdings aus dem Netz oder von erfahreneren Arbeitskollegen.

Zum Coden an sich:

Ich schieße aus der Hüfte, und halte meinen Code bewusst so modular wie möglich. Das macht es mir einfacher, einzelne Module auf bestimmte Aspekte hin zu optimieren.

Zur "Güte" meines Codes hole ich mir auch die Meinung von erfahrenen Kollegen ein, die spätestens beim Review sowieso ihre Nase reinstecken müssen.


Manchmal bekomme ich natürlich auch ein festgenageltes Design hingelegt und rattere dann nur noch runter. Bei dieser Art von Code mache ich dann aber auch nichts weiter, als meine Minimalpflicht zu erfüllen. Kunde zufrieden bedeutet in dem Fall: Guter Code, auch wenn ich das anders sehe. Aber meine Meinung zählt in solchen Fällen nicht ^^

[Prian]

Er hat Jehova gesagt. Hat er. Gaanz sicher. Jehova (https://www.google.de/search?q=kernighan+c+buch&sa=X&hl=de&gbv=1&sei=3Y4mVb2oIYGgsAHB6oGQBQ)

[Baalzamon]

Im Endeffekt frage ich mich halt: Was ist 'guter' Code?

Sind es all die trivialen (so erscheinen sie mir zumindest) Dinge wie sinnvolle Variabelnamen, korrekte Einrückungen, durchgängige Namenskonventionen usw.

Oder steckt da noch mehr dahinter, was ich irgendwie noch nicht mitbekommen habe.

Ich würde ja meinen Code auch gerne von einem Kollegen checken lassen, aber was tun wenn man keine Kollegen hat oder man unter den Kollegen schon derjenige ist, der die meiste Programmiererfahrung hat?

[Mosher]

Naja, "guter" Code findet auf mehreren Ebenen statt.

Das mit den Variablennamen, Einrückungen etc. würde ich unter dem Punkt Lesbarkeit zusammenfassen.

Dann gehört zu einem guten Code noch eine gute Dokumentation. Minimal: Kommentare. Wünschenswert: HTML-Dokumentation á la Doxygen.

Und dann wären natürlich noch die technischen Aspekte wie Effizienz (hinsichtlich Speicher, hinsichtlich Performance), Fehlerbehandlung...

Gerade für die Effizienz muss man sich eigentlich mehr mit der Plattform, auf der der das Programm laufen soll, befassen, als mit dem Code an sich.
Der eine kann gut float, beim anderen arbeitest du lieber mit Festkommaarithmetik, um mal ein Beispiel zu nennen.

Es ist immer nützlich zu wissen, wie viel Zeit deine Plattform für welche Operation braucht.
Behält man da immer den Überblick, fällt es auch leichter, Auswirkungen von Nebenläufigkeit abzuschätzen.

und und und.



Beispiel: Ich hatte einen Funksender zu designen und hatte die Wahl zwischen 2 Mikroprozessoren. Preisunterschied: ca. 1€.
Durch ein bisschen Trickserei im vorhandenen Code und durch gnadenloses überschreiben des Programmspeichers, um dort noch 16 Bytes für die Verschlüsselung unterzubringen, konnten wir den kleineren Prozessor nehmen.

Der Code war eigentlich beschissen und langsam, aber da wir auf Kosten optimieren wollten, für diesen Anwendungsfall perfekt. Die paar Hertz weniger, mit der die Hauptschleife durchlief waren in dem Fall zu verschmerzen.

[Simon]

Zum Programmieren gehoert auch vieles anderes als die drei genannten Buecher. Dieses Buch sollte nirgends fehlen: https://pragprog.com/book/jkthp/the-healthy-programmer

[Baalzamon]

Naja, "guter" Code findet auf mehreren Ebenen statt.

Das mit den Variablennamen, Einrückungen etc. würde ich unter dem Punkt Lesbarkeit zusammenfassen.

Dann gehört zu einem guten Code noch eine gute Dokumentation. Minimal: Kommentare. Wünschenswert: HTML-Dokumentation á la Doxygen.

Und dann wären natürlich noch die technischen Aspekte wie Effizienz (hinsichtlich Speicher, hinsichtlich Performance), Fehlerbehandlung...

Gerade für die Effizienz muss man sich eigentlich mehr mit der Plattform, auf der der das Programm laufen soll, befassen, als mit dem Code an sich.
Der eine kann gut float, beim anderen arbeitest du lieber mit Festkommaarithmetik, um mal ein Beispiel zu nennen.

Es ist immer nützlich zu wissen, wie viel Zeit deine Plattform für welche Operation braucht.
Behält man da immer den Überblick, fällt es auch leichter, Auswirkungen von Nebenläufigkeit abzuschätzen.

und und und.
Hmmm... das bestätigt mich nur mehr in meiner Ansicht, dass 'guter' Code sowieso von alleine anfällt, wenn man sich auch nur die geringsten Gedanken um das macht, was man da programmiert. Was man mMn sowieso tun sollte, wenn man professionell programmiert und nicht nur hobby-mäßig unterwegs ist.

Mein Problem damit ist eher, dass es irgendwie keine 'objektiven' Kriterien zu geben scheint. OK, bei Effizenz schon, man kann halt ne Laufzeitanalyse machen und dann schön sagen, wir haben hier ein O(n²) oder sowas.

Aber zB. Lesbarkeit ist nun mal sehr subjektiv, ebenso wie Kommentare. Der Eine würde am liebsten nur noch in 'literal Haskell' schreiben, für den anderen ist jede Zeile Kommentar nur ein Beweis dafür, dass man keinen verständlichen Code schreiben kann, usw. usw.

Zum Programmieren gehoert auch vieles anderes als die drei genannten Buecher. Dieses Buch sollte nirgends fehlen: https://pragprog.com/book/jkthp/the-healthy-programmer
Das ist zwar interessant aber leider überhaupt nicht zum Thema. ;(

[Mosher]

Was die Lesbarkeit betrifft, hat da wohl jede Firma / jedes Team ihre eigenen Vorstellungen und Richtlinien, da hast du Recht mit der Subjektivität.

Für vieles gibt es aber auch Kosmetik-Tools, mit denen man seinen Code nachträglich umschreiben kann, wenn man mit seinem eigenen Stil besser klarkommt, aber der Code hinterher "firmenrichtlinienkonform" aussehen soll.
Ist bei uns ausdrücklich erlaubt.


Es ist vermutlich sehr viel einfacher, allgemeingültige Kriterien für schlechten Code zu finden:

- Keine Dokumentation
- Spaghetticode
- nichtssagende Variablen
- unnötige Redundanzen
.
.
.

[Simon]

Das ist zwar interessant aber leider überhaupt nicht zum Thema. ;(
Guter Code fängt mit einem Körper und Geist in gutem Zustand an. Dann kann man die Bücher oben aus der Liste nehmen.

Mein Problem damit ist eher, dass es irgendwie keine 'objektiven' Kriterien zu geben scheint. OK, bei Effizenz schon, man kann halt ne Laufzeitanalyse machen und dann schön sagen, wir haben hier ein O(n²) oder sowas.
Effizienz mit big-O hat in der Praxis immer weniger Relevanz. Da spielen andere Faktoren wie Speicherbandbreite, Cache Hits/Misses, Register Usage eine grosse Rolle. Ich hab hier Code mit O(n) der ist mit seinen Aufgaben schneller fertig als Code mit O(log(n)).

Falls es dir um Reviews geht, hast du das mal probiert: http://codereview.stackexchange.com/ ?

Oder: http://www.codereviewers.com/

Ansonsten:

User Groups
Ingenieure anderer Firmen
Freunde


Je länger ich diesen Job mache, desto mehr stimme ich dem zu:
http://mordor.digitaldarkness.com/rock-solid-dallasphp-2012/images/code-review.png

[Godmode]

Im Endeffekt frage ich mich halt: Was ist 'guter' Code?


Es kommt wie immer auf den Anwendungsfall an. Bei mir muss der Code an erster Stelle verständlich und gut leserlich sein. Code wird öfter gelesen als geschrieben. Ich schreibe gerne ausdrucksstarken Code, kurze Methoden, kleine Klassen, keine God-Objects, Interfaces möglichst schmal halten, etc. Auf der anderen Seite aufpassen, dass man kein Over-Engineering betreibt, der Code sollte die Anforderungen abdecken sonst nichts. Kommentare sind auch sehr wichtig. Wenn ich merke das ich sehr viele Kommentare schreiben muss, um ein Stück Code zu beschreiben, ist das oft ein Zeichen, dass der Code zu kompliziert ist.

Besser wird man nur durch lesen gutem Code, bzw. Code Reviews mit einem Entwickler der ein höheres Level hat, als man selber hat.

[RLZ]

Hmmm... das bestätigt mich nur mehr in meiner Ansicht, dass 'guter' Code sowieso von alleine anfällt, wenn man sich auch nur die geringsten Gedanken um das macht, was man da programmiert. Was man mMn sowieso tun sollte, wenn man professionell programmiert und nicht nur hobby-mäßig unterwegs ist.(
Das endet darin, dass jeder Entwickler bei Null anfängt.

Bücher über das Thema machen Sinn, weil es da draußen Menschen gibt, die versuchen herausfinden wie man guten Quellcode schreibt. Vieles was in den Büchern steht mag einen selbstverständlich vorkommen, aber das ist vorallem eine pyschologische Sache. Selbst der Hinweis "das sollte man wirklich so machen" hilft schon und oft sind es nur kleine Hinweise und Denkanstöße, die einem langfristig weiterhelfen.

[Monger]

Hmmm... das bestätigt mich nur mehr in meiner Ansicht, dass 'guter' Code sowieso von alleine anfällt, wenn man sich auch nur die geringsten Gedanken um das macht, was man da programmiert. Was man mMn sowieso tun sollte, wenn man professionell programmiert und nicht nur hobby-mäßig unterwegs ist.

Der Weg ist wesentlich weiter als man denkt. Codequalität fängt bei sauberer Syntax an, und hört dort nicht etwa auf. Selbst Entwickler die 20 Jahre entwickelt haben, lernen immer noch wie man Code noch klarer und besser schreiben kann. Ich hab noch niemanden erlebt bei dem dieser Lernprozess je abgeschlossen gewesen wäre.


Mein Problem damit ist eher, dass es irgendwie keine 'objektiven' Kriterien zu geben scheint. OK, bei Effizenz schon, man kann halt ne Laufzeitanalyse machen und dann schön sagen, wir haben hier ein O(n²) oder sowas.

Codequalität ist etwas kulturelles: jedes Team, jede Firma muss da eine eigene Kultur entwickeln was man sich selbst als Qualitätsmaßstab anlegen will und was nicht.
Weil es was kulturelles ist, ist es auch Trends unterworfen: lesbarer Code sah vor 20 Jahren völlig anders aus als heute. Gibt halt heute andere Trends, andere Paradigmen die relevant sind.
Deshalb ist es schwer da ein Standardwerk zu empfehlen. Gibt halt keine fixe und unumstößliche Definition von "gut".

[Shink]

Ich halte relativ wenig von Büchern zum Programmieren allgemein (Außer vielleicht als Anfänger)
Naja, die "Klassiker" kann man schon lesen. Man muss sich ja dann nicht daran halten. Aber so eingängiges Zeug wie Extreme Programming, The Pragmatic Programmer, Clean Code, Patterns of Enterprise Application Architecture o.ä. kann man sich schon antun.

Code aus der Hüfte schiessen? Vorher das Design total festlegen und dann nur noch runterprogrammieren?
Aus der Hüfte schießen, solange es funktioniert. Wenn man mit fremden Teilen zusammen arbeitet, muss man vorhin ohnehin etwas Design erzeugen.
Wenn man jemanden anderen darauf ansetzt oder etwas übergeben muss auch.
Und dann: Perestroika. Refactoring bis der Arzt kommt, dann weiß man auch, ob man genug Testabdeckung hat.:D Denn im Nachhinein weiß man es ja ohnehin besser.

[Shink]

Ach ja: An die "Es gibt ja keine objektiven Kriterien" - Typen: Statische Codeanalyse (etwas wie SonarQube) verwendet ihr wohl nicht?

[Monger]

Ach ja: An die "Es gibt ja keine objektiven Kriterien" - Typen: Statische Codeanalyse (etwas wie SonarQube) verwendet ihr wohl nicht?
Auch Regeln für statische Codeanalyse müssen von irgendjemandem erstmal akzeptiert werden. Wenn man ein Team ohne Erklärung und Abstimmung mit Warnungen aus der statischen Codeanalyse erschlägt, wird es schnell Wege finden diese zu ignorieren.
Entwickler sind kreativ, und hassen es bevormundet zu werden.

Im übrigen gibt es ja für SonarQube o.ä. selten nur einen standardisierten Regelsatz, sondern gleich eine ganze Menge davon. Welcher davon der richtige ist, ist ja auch immer offen für Interpretation.

[Simon]

Ach ja: An die "Es gibt ja keine objektiven Kriterien" - Typen: Statische Codeanalyse (etwas wie SonarQube) verwendet ihr wohl nicht?
Doch, sicher mit Coverity. Allerdings kann das unter anderem nicht die Frage beantworten ob Code jetzt leicht verstaendlich ist.

[Ectoplasma]

Im Prinzip erlebst du folgendes im Laufe deines beruflichen Werdeganges. Bei einer simplen Aufgabe wie: "was ist 5 * 8?" kann es durchaus mehrere Lösungen geben.

erste Lösung:


float x = 5 * 8;


die andere etwas seltsame Lösung:


float x = 0;

for (int i = 0; i < 5; ++i) {
x += 8;
}


Die Aufgabe ist jetzt im übertragenen Sinne zu verstehen. Du wirst feststellen, dass du in keinem Buch der Welt ein generelles Rezept finden wirst, wie man für jedes Problem eine optimale Lösung findet. Hier ist einfach nur üben, üben und nochmals üben angesagt.

Was Typ -und Variablennamen anbelangt, kann ich nur sagen, dass sie das Salz in der Suppe sind. Sie bilden die Semantik des Problems ab. Wer schlechte Namen verwendet, hat oft auch das Problem nicht komplett verstanden. Das ist zumindest meine Beobachtung.

Dem hier kann ich allerdings nur beipflichten.


http://mordor.digitaldarkness.com/rock-solid-dallasphp-2012/images/code-review.png

[Monger]

Nachdem mich mal wieder das große Zweifeln übermannt hat, ich schon seit ewigen Zeiten in meinem eigenen Saft brodel und ich keine Ahnung habe, ob der Code den ich so fabriziere auch nur im geringsten gut ist (whatever that means)...

Ah, da fällt mir ein: Tests sind ein erstaunlich guter Indikator dafür ob der Code verständlich ist. Das fängt beim Namen an: wenn du versucht bist irgendwas zu schreiben à la "MethodX_does_some_magic_then_it_doesnt_crash", dann ist das ein guter Indikator dafür dass du selber nicht so genau weißt was dein Code eigentlich tut.

Viele Entwickler werden erst dann ernsthaft mit Codequalität konfrontiert sobald sie sich selbst mal um Unit Tests kümmern müssen.

[Baalzamon]

Ich danke euch für eure zahlreichen und mitunter hilfreichen Antworten.

Vielleicht muss ich mal kurz was zu mir sagen, damit ihr meine Lage besser einschätzen köntn und meine Motivation warum ich hier diesen Thread eröffnet habe.

Ich habe ein Diplom in Informatik und mehr als 10 Jahre als Softwareentwickler gearbeitet., Aber, und das ist die Krux an der Sache, ich habe immer alleine gearbeitet. Ich musste mich so gut wie nie mit anderen Leuten abstimmen, ich war der einzige der an meinem Code gearbeitet hat und wenn ich doch mal mit jemandem zusammen an einem Projekt gearbeitet habe, dann war ich derjenige mit mehr Erfahrung. ;(

Dementsprechend glaube ich zwar, dass ich ganz guten Code und lesbaren fabriziere, aber wissen tue ich es halt nicht, da mir das Feedback fehlt. Deshalb dieser Thread um mal zu fragen wie andere Programmierer das so handhaben.

Ich habe mal flink SonarQube installiert und über das letzte kleine Projekt von mir laufen lassen (1163 loc) und das gibt einem ja zumindest schonmal eine grobe Ahnung davon, was so schief läuft. Nicht ganz ohne Stolz kann ich auch sagen, dass das Projekt gar nicht soooo schlecht aussah. 0.0% Duplicity und die meisten 'Anmerkungen' sind 'Space statt Tabs'. ;)

Natürlich sind auch ein paar Sachen dabei die mir einfach durchgerutscht sind, switches ohne default usw. aber alles in allem gibt mir das erstmal das Gefühl, dass ich vielleicht doch gar nicht so Scheisse programmiere wie ich befürchtet habe.

Simons Bild kann ich auchnur zustimmen und ist lustigerweise dierkt auf den ersten paar Seiten von 'Clean Code' abgedruckt, dass ich mir hier aus der Bibliothek ausgeliehen habe.

Und vielen Dank für die Stackexchange-Coderview Seite... die kannte ich noch nicht und werde da vielleicht einfach mal ein paar Code-Samples von mir hochladen und gucken was andere Leute dazu sagen.

Alles in allem bestärken mich eure Aussagen aber darin, dass es halt nicht den guten Code gibt, sondern das knallhart von der Umgebung und den persönlichen Vorlieben abhängt.

[Mosher]

Ja, mir geht es ähnlich. Ich habe mich sehr lange nie für meinen Code rechtfertigen müssen, da ich alleine gearbeitet hatte. Das hat sich aber mittlerweile geändert und ich schreibe auch wiederverwendbare Code-Schnipsel, von denen die Kollegen auch noch in 5 Jahren profitieren sollen.

Ideal wäre natürlich einen Copa&Paste-fähigen Code zu schreiben, bei dem Plattformfragen über defines geregelt sind, aber in 99% der Fälle bedarf es trotzdem Anpassungen.

Wenn der Kollege dann denn Code sieht und sagt:
"Ok, den nehme ich und mache ein paar Anpassungen", dann ist es guter Code
"Hm, ich glaube, ich schreibe doch lieber alles neu" deutet auf schlechten Code hin, oder vielleicht auch darauf, "dass der Typ meinem Code nicht gewachsen ist" -> Aber so etwas darf es eigentlich nicht geben.

[Simon]

Wenn der Kollege dann denn Code sieht und sagt:
"Ok, den nehme ich und mache ein paar Anpassungen", dann ist es guter Code
"Hm, ich glaube, ich schreibe doch lieber alles neu" deutet auf schlechten Code hin, oder vielleicht auch darauf, "dass der Typ meinem Code nicht gewachsen ist" -> Aber so etwas darf es eigentlich nicht geben.
Es gibt auch sehr viele Leute, die Sachen neu schreiben wegen NIH-Syndrom oder weil sie nicht wissen, dass schon was passendes existiert. Letzteres ist bei Anfängern sehr gängig.


Dementsprechend glaube ich zwar, dass ich ganz guten Code und lesbaren fabriziere, aber wissen tue ich es halt nicht, da mir das Feedback fehlt. Deshalb dieser Thread um mal zu fragen wie andere Programmierer das so handhaben.
Die Stackexchange-Seite ist für kleine Sachen gedacht.
Falls du wirklich Erfahrung im Team und Feedback suchst:
- such dir ein OSS-Projekt deiner Wahl. Am besten eins was schon lange besteht und mit 10+ Leuten
- such dir ein Hacker Camp, die kosten eventuell. Sowas: https://www.recurse.com/about
- such dir ein Code Camp in der nächsten Stadt

Hier in den USA gibt es die letzten beiden Sachen in jeder mittelgrossen Stadt. Wie das in Deutschland aussieht, kann ich nicht sagen.

[Baalzamon]

Um mal ein kurzes Update zu geben:

Ich bin inzwischen mit 'Clean Code' durch und Uncle Bob hatte noch so einige gute Hinweise für mich parat. Ich kann tatsächlich jedem empfehlen dieses (oder ien Buch dieser Art) mal gelesen zu haben, auch wenn man natürlich selber noch mal wertet, welche 'Regeln' man wirklich in seine tägliche Arbeit übernehmen will.