Programmierbücher die man gelesen haben muss

[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!

[memphis]

die Beispiele sind Java.

[taaktaak]

Mille grazie!

[Phoenix]

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 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.