Programmierbücher die man gelesen haben muss

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