Programmierbücher die man gelesen haben muss

[quantum]

Es gibt Bücher, die uns die Augen öffnen oder den letzten Schub verleihen können, um uns zu besseren Programmierern zu machen.
Solch ein Top-Buch ist für mich "Code Complete" von Steve McConnell. Fast schon meine Bibel.
Es gab mir einige Schläge auf den Hinterkopf, welche mir endgültig die Quick&Dirty Methode austrieb und mich zu sauberen Quelltext führte, der gut riecht.
Nicht zu vergessen, "Der pragmatische Programmierer" von Andrew Hunt und David Thomas.
Das Buch "Clean Code" habe ich mir in der deutschen Ausgabe vorbestellt, es soll die pragmatische Methode praxisnah vertiefen.
Die Rezensionen könnt ihr zb bei Amazon nachlesen (in "Der pragmatische Programmierer" ist das Mantra "DRY - DONT REPEAT YOURSELF") :-)

Welche Bücher veränderten und verbesserten eure Arbeitsweise?

[Hansa]

An erster Stelle stehen immer noch die Delphi-Handbücher. Direkt danach (also vertiefend) kommen die von Marco Cantu. Habe letzte Woche mitbekommen, dass das neue D2009 Buch im Mai kommt und sogar auf deutsch. 8)

[memphis]

• Effective Java
• Agile Java: Crafting Code with Test-Driven Development
• Getting Things done
• The Pragmatic Programmer
• Clean Code (hat mir sehr gut gefallen!)

"97 Things Every Software Architect Should Know" möchte ich bei Gelegenheit auch lesen...

[Phoenix]

Ich habe 'Clean Code' im englischen Original gelesen (okay... ich bin noch nicht ganz durch, aber mehr als die Hälfte hab ich schon geschafft ;-) ) und muss sagen, dass die Beispiele dort einem echt die Augen öffnen.

[Luckie]

Kannst du mal ein Beispiel machen?

[Florian Hämmerle]

wer hat denn Clean Code geschrieben?

mfg Flö

[Phoenix]

Clean Code ist von Robert C. Martin. Im Internet eher als UncleBob bekannt.

Ein Beispiel... gute Frage.
In dem Buch sind halt viele Quellcodebeispiele gebracht. Ein Code, ca. eine Buchseite, zwei oder drei Funktionen. Im Text ist angegeben, das man sich mal 3 Minuten Zeit nehmen sollte den Code zu verstehen. Ich habs nicht geschafft. Dann wird anhand dieses Codes erklärt, was er warum umbenennt, was er warum in einzelne Funktionen rauszieht etc.

Hinterher hat er zwar in der Menge mehr code (weil mehr Funktionen -> Mehr Funktionsrümpfe), aber pro Funktion weniger Code, deutlich bessere Benamsung, die Funktionen sind von großer Abstraktion nach kleinerer Abstraktion sortiert und man versteht den neuen Code schon beim einfachen durchlesen.

Ich finde es einfach grandios, was man mit einem kleinen bisschen mehr an Sorgfalt beim Programmieren erreichen kann.

[Luckie]

Klingt gut. Ich habe es mal auf meinen Amazon Wunschzettel vermerkt. Wer sich also bemüßigt fühlt... :mrgreen:

[taaktaak]

Zitat:

Clean Code ist von Robert C. Martin.....
In dem Buch sind halt viele Quellcodebeispiele gebracht.

In welche Sprache sind die Beispiele?
Delphi, C, ...?

[Luckie]

So lange es nicht Brainfuck oder Lisp ist, ist es eigentlich unerheblich. ;)

[taaktaak]

Hmmm,
für mich aber eben leider nicht so ganz unerheblich
:(

[Luckie]

Also komm. Du kannst Delphi, da solltets du mit dem Lesen con C, C++, C# oder Java keine Probleme haben. Und eine dieser Sprachen wird es ein.

[taaktaak]

Dein Vertrauen ehrt mich,
dann werde ich mich mal überraschen lassen!
:thumb:

[memphis]

die Beispiele sind Java.

[taaktaak]

Mille grazie!

[Phoenix]

Zitat:

Zitat von taaktaak

Zitat:

Clean Code ist von Robert C. Martin.....
In dem Buch sind halt viele Quellcodebeispiele gebracht.

In welche Sprache sind die Beispiele?
Delphi, C, ...?

Die Beispiele im Buch sind in Java.
Aber: Es sind keine tiefergehenden Java-Kenntnisse vonnöten. Code ist Code, und er bezieht sich nicht auf Bibliotheken. Der Code den er nimmt ist in sich geschlossen bzw. ruft nur Dinge auf, die im gleichen Codesample auch implementiert sind.

Wenn Robert Martin an einer Stelle von Map oder Hashmap schreibt, ist das im Prinzip sowas wie eine TList, das ist aber ganz ehrlich bisher die einzige Stelle gewesen, wo er ein Java-Fachwort eingeworfen hat das ich nicht auf Anhieb verstanden hatte.

[taaktaak]

Danke, dann werd' ich's mal lesen.
Mein größtes Problem sehe ich wohl auch eher darin, dass trotz ehrlichem Vorsatz, es besser zu machen, die jahrelange prozedurale Programmierung immer wieder zum Vorschein kommt. Und wenn es dann auch gleich so schön funktioniert, dann sagt das "kleine Teufelchen im Hinterkopf": Warum willst du es denn anders machen?

[Phoenix]

Zitat:

Zitat von taaktaak

Und wenn es dann auch gleich so schön funktioniert, dann sagt das "kleine Teufelchen im Hinterkopf": Warum willst du es denn anders machen?

Um Dir selber einen Gefallen zu tun.

Ein Code wird genau ein einziges mal geschrieben.
Der gleiche Code wird jahrelang immer wieder gelesen und ggf. leicht abgeändert.
Du bist mit aller Wahrscheinlichkeit derjenige, der in 2, 3 Monaten wieder Deinen eigenen Code lesen darf.

Wie oft ist es schon vorgekommen, dass Du Dich gefragt hast warum Du das damals so geschrieben hast? Anders wärs doch eigentlich besser...

Warum änderst Du den Code dann nicht einfach so, dass er besser wird?
Weil Du Angst hast, dass Deine Änderungen ggf. etwas kaputt machen könnten.
Ergebnis: Alter, schlechter Code bleibt schlecht und wird durch neuen, zwangsläufig auch nicht optimalen Code ergänzt.

Das ganze System verrottet mit der Zeit, und der Aufwand der für die Wartung getrieben werden muss, wird immer größer und größer.

Die Angst, dass Änderungen etwas kaputt machen können nimmst Du Dir durch (automatisierte) Tests. Wenn Du was änderst wird Dir ein Test sagen, ob etwas kaputt gegangen ist oder nicht. Voraussetzung für Tests ist aber sauberer Code mit wohldefinierten Zuständigkeiten.

Wenn Du Dich also in die in dem Buch vorgstellten SOLID Prinzipien hältst, dann erhältst Du hinterher besseren und leichter testbaren Code. Und der erlaubt es Dir dann, Änderungen (Verbesserungen!) zu machen, ohne dass Du Angst haben musst, dabei etwas kaputt zu machen.

[memphis]

ganz genau. Vor allem wenn ich vor Ort ganz schnell ein Feature für einen Kunden implementieren musste, hatte ich früher sehr oft ein ungutes Gefühl und hoffte, dass alles noch einwandfrei funktioniert. Jetzt habe ich innerhalb von Sekunden mit meinen Tests eine eindeutige Bestätigung (ich kann nicht nur um einiges besser schlafen, sondern drücke mich auch nicht mehr vor Änderungen ;)).

[taaktaak]

Ja, die Vorzüge habe ich wohl verstanden. Wenn ich meinen "Reifeprozess" der letzten Jahre anhand von verschiedenen Source-Jahrgängen betrachte, ist auch eine deutliche Verbesserung in genau diese Richtung zu erkennen. Einen wesentlichen Anteil daran hat auch dieses Forum. Als Hobbyprogrammierer hat man leider häufig den Nachteil, weder eine solide Basis zu besitzen, noch wird durch berufliche Notwendigkeiten ein Optimierungsdruck erzeugt.
Habe mir das Buch heute Abend bestellt - die Weiterentwicklung meiner handwerklichen Fähigkeiten wird also bestimmt fortgesetzt. :-D

[Luckie]

Zitat:

Zitat von Luckie

Klingt gut. Ich habe es mal auf meinen Amazon Wunschzettel vermerkt. Wer sich also bemüßigt fühlt... :mrgreen:

Und schon ist es wieder runter (Code Clean). Ein guter Geist und Gönner :drunken: hier im Forum, bei dem ich mich noch mals herzlich bedanken will :cheers:, hat es mir wohl gerade gekauft. :firejump:

Ich sehe gerade am 15. März erscheint es auch auf deutsch.

Gibt es eigentlich auch bei Dell oder HP Wunschzettel? :mrgreen: :duck:

[quantum]

Das mit den Tests ist ein gutes Beispiel. Um überhaupt testen zu können, muss man Code schreiben, der wirklich entkoppelt ist. Also keine bis wenige Abhängigkeiten besitzt. Somit bekommt man allein durch diesen Vorsatz, 2 Fliegen mit einer Klappe geschlagen.
Manchmal muss ich lachen wenn ich an meinen ersten Versuch denke, einen Unit-Test für ein bestehendes Monster-Projekt zu schreiben. Da hing fast jede Klasse mit allen anderen zusammen. Es war unmöglich einen isolierten Test du schreiben.
Was Kapselung wirklich bedeutet und wofür es gut ist, zeigten mir erst die geliebten Design-Patterns.
Oftmals ärgerte ich mich über die Einschränkungen von Delphi (keine Mehrfachvererbung, strenge Typisierung), die ich als Nachteil betrachtete. Dabei sind dies enorme Vorteile. Mehrfachvererbung verletzt eindeutig das Kapselungsprinzip und unterstützt nur die Faulheit. Wer mal versucht in PHP ein größeres Projekt aufzuziehen, wird sich nach eindeutigen Typen und der Reinheit von Delphi sehnen.
Dies war jetzt wohl ein wenig Off-Topic, aber als Thread-Eröffner möge mir man dies verzeihen :wink:

[freak4fun]

Zitat:

Zitat von Luckie

Ich sehe gerade am 15. März erscheint es auch auf deutsch.

Gibt es eigentlich auch bei Dell oder HP Wunschzettel? :mrgreen: :duck:

Ich hab's mal vorbestellt. Allerdings für mich. :mrgreen:

[Luckie]

Also Clean Code ist wirklich super. Es enthält viele Tipps und Grundsätze, um sauberen Code zu schreiben. Jeder Tipp oder Grundsatz wird begründet und mit Code (Java) verdeutlicht. Allerdings muss ich sagen, dass ich auch schon einiges instiktiv richtig gemacht habe, was zum Beispiel die Benennung von Bezeichner angeht oder die Strukturierung von Code. Und ich habe darüber schon mal einen Artikel geschrieben: Code Design.

Ich habe mal angefangen und die wichtigsten Grundsätze rauszuschreiben: Clean Code. Dies soll natürlich nicht das Buch ersetzen, sondern nur eine Übersicht sein. Denn letzt endlich ist es so viel, dass man das nur verinnerlichen kann, wenn man Code schreibt, Code schreibt und noch mals Code schreibt und bestehenden Code immer wieder überarbeitet.

Also ich kann das Buch nur jedem empfehlen, der seinen Code und Programmierstil verbessern will. Eventuell werde ich mir auch mal die deutsche Ausgabe zu legen, da es nicht ganz einfach auf englisch zu lesen ist.

[himitsu]

Zitat:

Genau so sind Vorsilben für Attribute einer Klasse überflüssig.

ich war schon fast davor sowas bei mir einzuführen ... nja, zum Glück hatte ich mich dann doch dagegen währen können :angel:


@Luckie: einen Fehler hast'e aber drin

Zitat:

Fehlerbehandlung
* Man sollte den try-except-finally-Block zu erst schreiben und dann den Code.

ok, da war zwar noch Einer, aber den fand ich grad nicht wieder :oops:

[memphis]

Einige gute Artikel in deutscher Sprache zu "Clean-Code" findet man auch unter Clean-Code-Developer (Sebastian hat dieses Thema bereits hier angesprochen, leider hat es damals nicht sehr viel Interesse geweckt...).

[Luckie]

@himitsu: Nur zwei Fehler? Da sind bestimmt mehr drinne. Wenn man bedenkt, wann ich das getippt habe und dass ich da schon eine halbe Flasche Wein intus hatte. :mrgreen:

[himitsu]

Ich war seit fast 30 Stündchen wach und war/bin immernoch nicht ganz gesund ... kann ja demnächst gern nochma suchen :angel:

du säufst aber ganz schön viel, in letzter Zeit :shock:

[freak4fun]

Mein Buch (Clean Code - Deutsche Ausgabe) ist nun da. Ich war leider nicht da, aber kann es morgen von der Post abholen. *freu*

[schöni]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von taaktaak

Und wenn es dann auch gleich so schön funktioniert, dann sagt das "kleine Teufelchen im Hinterkopf": Warum willst du es denn anders machen?

Um Dir selber einen Gefallen zu tun.

Ein Code wird genau ein einziges mal geschrieben.
Der gleiche Code wird jahrelang immer wieder gelesen und ggf. leicht abgeändert.
Du bist mit aller Wahrscheinlichkeit derjenige, der in 2, 3 Monaten wieder Deinen eigenen Code lesen darf.

Wie oft ist es schon vorgekommen, dass Du Dich gefragt hast warum Du das damals so geschrieben hast? Anders wärs doch eigentlich besser...

Warum änderst Du den Code dann nicht einfach so, dass er besser wird?
Weil Du Angst hast, dass Deine Änderungen ggf. etwas kaputt machen könnten.
Ergebnis: Alter, schlechter Code bleibt schlecht und wird durch neuen, zwangsläufig auch nicht optimalen Code ergänzt.

Das ganze System verrottet mit der Zeit, und der Aufwand der für die Wartung getrieben werden muss, wird immer größer und größer.

Die Angst, dass Änderungen etwas kaputt machen können nimmst Du Dir durch (automatisierte) Tests. Wenn Du was änderst wird Dir ein Test sagen, ob etwas kaputt gegangen ist oder nicht. Voraussetzung für Tests ist aber sauberer Code mit wohldefinierten Zuständigkeiten.

Wenn Du Dich also in die in dem Buch vorgstellten SOLID Prinzipien hältst, dann erhältst Du hinterher besseren und leichter testbaren Code. Und der erlaubt es Dir dann, Änderungen (Verbesserungen!) zu machen, ohne dass Du Angst haben musst, dabei etwas kaputt zu machen.

Da wär ja ein Buch über Unittests gut. Hab da schon bissl Online Dokud angeguckt. Im Delphi Treff ist auch eine Einführung.

Was ich aber dabei noch nicht verstehe ist:

Teste ich dabei prozeduren + Funktionen, gewissermassen jede Prozedur/Funktion einzeln?

Gut, ich könnte auch ne Klasse testen, infem ich sie von DUnit Framework teste.

Aber ist das eher ein Verfahren was zu mehr Disziplin beim Testen zwingt oder worin liegt der Vorteil?

Delphi-Quellcode:

//Aus dem Delphi Treff Tutorial zu DUnit:
type TAddressTest = class(TTestCase)
  private
    FAddressBook: TAddressbook;
  protected
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure TestOne; //Hierfür muss ich genauso meinenTestroutinen schreiben
    procedure TestTwo; //ZB. meine Klassenmethode, die dann halt vor Einsatz getestet wird.
end;

Nun würde ich zu testende Methoden von TestOne, TestTwo... aufrufen lassen.

Ich könnte aber ebenso gut meine Klasse normal entwickeln, ohne DUnit und dann genauso jede Methode testen, nachdem ich Code reingeschrieben habe. In beiden Fällen muss ich selber die nötige Disziplin aufbringen, die Tests auch durchzuführen.

Wenn also der Test mit DUnit besser sein soll, hab ich was grundsätzliches noch nicht verstanden. Wo also kann ich mich da schlau machen? Das Delphi Treff Handbuch ist da zu kurz.



Da es aber hier eigentlich um Buchempfehlungen geht, statt um Fragen zu guten Programmierbüchern, empfehle ich hier das

"Delphi X Kochbuch" von Deberenz/Kowalski, Hanser Verlag.

Das X steht für die Delphi Version. Das Buch gibt Rezeptlösungen im Sinne von Wie kann ich:

-einen Splash Screen programmieren
-eine Bitmap drehen
.....

Mir hat das nach dem Buch "Delphi 3.0 lernen" ein Ganzes Stück weiter geholfen. "Delphi 3.0 lernen" ist für absolute Newbies geschrieben. Wer dann weiter will, für den ist das Delphi X Kochbuch genau das Richtige. Erst danach ist weiterführende Delphi Literatur zu empfeheln. Wie das Delphi Entwicklerhandbuch. Hab ich für Delphi 4, ist aber mit dem was dort beschrieben wird immer noch aktuell.

"Delphi 4 Developers Guide" von Steve Teixeira & Xavier Pacheco.

Da wird auf das Windows API eingegangen, Dll Programmierung behandelt, Hooks erklärt und vieles Andere mehr. Ist allerdings in englischer Sprache geschrieben.

[Chemiker]

Hallo,

interessante Bücher sind:

1. ) Algorithmen und Datenstrukturen von Niklaus Wirth
2. ) Algorithmen in C++ von Robert Sedgewick
3. ) Programmieren in C++ von Stephen C. Dewhurst und Kathy S. Stark

Zugegeben die Bücher sind nicht mehr ganz taufrisch, aber trotzdem sehr interessant.

Bis bald Chemiker

[3_of_8]

TAOCP!

[Luckie]

Zitat:

"Delphi X Kochbuch" von Deberenz/Kowalski, Hanser Verlag.

Überflüssig. Alle Rezepte findest du auch iregnd wo im Internet, in Foren oder Tricks und Tipps Sammlungen. Zu dem halte ich von den Autoren nicht allzu viel. Leider kann ich hier kein Beispiel nennen, aber ich hatte das Buch auch mal und musste feststellen, dass schlechter, wenn nicht sogar fehlerhafter Code in dem Buch zu finden war.

@Chemiker: Ein gutes Algorithmenbuch suche ich auch noch.

[3_of_8]

TAOCP ist das Algorithmenbuch überhaupt. :mrgreen:

Auch wenn man sich da wirklich durchlesen muss. Ist sehr aufschlussreich.

[Luckie]

Genauer Buchtitel und Autor wäre nicht schlecht.

[3_of_8]

Siehe Wikipedia: The Art of Computer Programming, Donald E. Knuth.

[Luckie]

Nun das halte ich dann doch für etwas zu viel des guten. Aber lustig ist, dass das Buch über Compiler wohl der letzte Band werden wird. Und erst ist gerade bei Band fünf von sieben. :mrgreen:

[BackOrifice]

Zitat:

Zitat von Luckie

Zitat:

"Delphi X Kochbuch" von Deberenz/Kowalski, Hanser Verlag.

Überflüssig. Alle Rezepte findest du auch iregnd wo im Internet, in Foren oder Tricks und Tipps Sammlungen. Zu dem halte ich von den Autoren nicht allzu viel. Leider kann ich hier kein Beispiel nennen, aber ich hatte das Buch auch mal und musste feststellen, dass schlechter, wenn nicht sogar fehlerhafter Code in dem Buch zu finden war.

Das stimmt wohl. Ich würde allerdings auch nie auf die Idee kommen, ein Beispie 1 zu 1 aus dem Buch abzutippen. Viel mehr ist dieses Buch als Nachschlagewerk (ich hab hier allerdings die "Grundlagen und Profiwissen"-Edition) zu benutzen und als Einstieg in ein neues Thema. Bspw. erkärt das Buch den Umgang mit INI-Dateien fürs Erste einfach. Möchte man mehr, muss man selbst weiter suchen. Das Spektrum, welches das Buch abdeckt ist größer, geht dafür auf keine Details ein.

[stoxx]

Zitat:

Überflüssig. Alle Rezepte findest du auch iregnd wo im Internet, in Foren oder Tricks und Tipps Sammlungen. Zu dem halte ich von den Autoren nicht allzu viel. Leider kann ich hier kein Beispiel nennen, aber ich hatte das Buch auch mal und musste feststellen, dass schlechter, wenn nicht sogar fehlerhafter Code in dem Buch zu finden war.

Ich würde sagen, die Bücher bekommen die Note gut bis befriedigend. Für einen Anfänger sind sie ein gutes Nachschlagewerk. Leider ist die Codequalität nicht die beste, Bücher wie Code Complete sind von der Qualität her auf einem ganz anderem Niveau, allerdings bezweifel ich, ob ein Anfänger die wahren Hintergründe versteht, oder ob man die Erfahrung einfach mal selber machen muss, dass man nach einem halben Jahr seinen eigenen Code anguckt und wie ein Schwein ins Uhrwerk schaut, um zu verstehen, dass die Qualität des Codes wichtiger ist, als am Anfang angenommen.

Vorteil des Buches ist aber definitiv, dass man sich von Luckie nicht sagen lassen muss,, dass man doch bitte selber Forensuche betreiben solle :-)
(hey .. nich persönlich nehmen, mag Dich ja trotzdem *g*)

[0xDEAD]

Mein Buchtipp SHIP IT!

Zitat:

Das Buch Ship it! Softwareprojekte erfolgreich zum Anbschluss bringen wurde von Jared R. Richardson und William A. Gwaltney geschrieben. Es beschäftigt sich mit den alltäglichen Problemen, die während eines Softwareprojekts oder der Arbeit im Team auftreten können.

Das Buch habe ich mir letztens bestellt und durchgelesen. Ich fand es sehr interessant und gut geschrieben. Es gibt einem gute Tipps wie man als Programmierer seine Arbeit und seinen Arbeitsalltag verbessern kann und zeigt einem auch gute praxisorientierte Beispiele. Es geht also nicht ums Programmieren ansich, sondern um die tägliche Arbeit mit dem Programmieren. Eine Menge der Tipps kannte ich schon aus dem Studium und meiner bisherigen Arbeit, bspw. Quellcodeverwaltung. Trotzdem ist das Buch sehr informativ und unterhaltsam geschrieben.
Besonders positiv finde ich, dass die Autoren bewußt OpenSource-Software einsetzen und ihre Beispiele zwar java-orientiert sind, aber sich auf alle anderen Programmiersprachen übertragen lassen.


Meine zweite Empfehlung ist das Thema Entwurfsmuster. :thumb:


Grundsätzlich bin ich der Meinung, dass es genug Websiten im Internet gibt auf denen man eine Menge guter Infos und Codebeispiele findet. Jedoch bietet die Qualität von Büchern meistens mehr als Websiten, wobei es da natürlich auch genug Ausnahmen gibt. ---> Und man hat was in der Hand. :wink:

Zur Zeit suche ich mehr Informationen über die Strukturierung und Realisation von großen Softwareprojekten und Softwareentwicklung en Detail (nicht nur Einführung).