Artikelformat

Rezension: The Art of Readable Code

Nachdem ich das Buch „The Art of Readable Code“ gelesen hatte, will euch meinen Eindruck dazu nicht vorenthalten. Wer das Buch „Clean Code“ kennt, in seiner Bibliothek stehen oder es auch einfach gelesen hat, braucht eigentlich nicht mehr weiter zu lesen, denn „The Art of Readable Code“ ist soetwas wie der kleine Bruder von „Clean Code“.

Auf Englisch wird hier in 190 Seiten eine kurze Übersicht gegeben, worauf es dabei ankommt, wenn man seinen Code lesbar schreiben will. Lesbarer Code ist nämlich immer gut, wenn man selbst zu einem späteren Zeitpunkt drauf schaut und direkt verstehen will, was man damals getan hat; aber auch damit die Arbeitskollegen oder allgemein andere Softwareentwickler sich schnell im fremden Code zurecht finden.

Insgesamt sind alle Kapitel mit Comics versehen, die das jeweilige Thema mit Humor untermalen. Daneben gibt es immer wieder Kurzfassungen des Prinzips – kann man auch Merksätze nennen – und am Ende jedes Kapitels eine Zusammenfassung der besprochenen Themen, sodass man sich schnell einen Überblick verschaffen kann. Codebeispiele dürfen in einem Buch über Code natürlich nicht fehlen und diese sind in verschiedenen Sprachen verfasst, sodass die typische Ausrede „das ist ja nicht in meiner Sprache geschrieben, damit kann ich gar nix anfangen“ nicht gilt. Interessant ist der dadurch gewonnene sehr kleine Einblick in andere Welten.

Die Themen im Überblick sind Coding Conventions, Code vereinfachen, Refactoring, Testing und ein Beispielprojekt.

Persönlich habe ich folgenden 3 Aspekte ausgewählt, die ich bei der Entwicklung verstärkt beachten will:

  • Code muss leicht lesbar sein, nicht hochoptimiert (außer in Ausnahmen)
  • Benutze nicht mehr als 4 Variablen pro Scope; mehr kann man nur schwerlich überblicken
  • Kommentiere nur sparsam, der Code selbst sollte schon lesbar und verständlich sein

Bei Google Books kann man sich selbst einen kleinen Überblick verschaffen – sehr praktisch!

3 Kommentare

  1. Kommentiere nur sparsam“ halte ich persönlich für einen schlechten Ansatz. Lieber ein Kommentar zu viel als zu wenig.
    Wichtiger ist doch, dass man sinnvoll kommentiert. Anstatt Dinge zu kommentieren die sich aus dem Code ergeben, eher das kommentieren was nicht so offensichtlich ist.
    Da sich mittlerweile die Datenströme über mehrere Dateien verteilen, wäre es z.B. sehr wichtig zu dokumentieren welche Funktion welche Daten an welche Datei übergibt. So hatte ich erst letztens das problem das ein JavaScript via Ajax aufgerufebn wurde, es aber nicht ganz klar war welche Dateien/Funktionen das JavaScript aufriefen. Das war eine fürchterliche Suche bis ich alle Aufrufe gefunden hatte. Ein sinnvoller Kommentar im JavaScript hätte diese Arbeit vermieden.

    Antworten
    • Du hast einen Punkt genau getroffen. Dinge die offensichtlich sind, braucht man nicht nochmals im Kommentar verewigen. Das ist sogar eine Fehlerquelle, weil man beim Ändern des Codes den Kommentar mit anpassen muss. Passiert dies nicht, laufen Code und Kommentar auseinander und das sorgt für eine entsprechende Verwirrung.
      Es verstecken sich aber noch weitere Punkte hinter der Aussage. Aber dafür geht man am besten ein kleines Stück zurück und betrachtet das eigentliche Problem. Warum schreibe ich einen Kommentar? Weil etwas unklar ist. Und wieso ist etwas unklar? Weil es vielleicht kompliziert ist. Okay, dann kann man einen Kommentar dran schreiben. Weil es unklar bezeichnet ist? Dann passe ich doch besser die Bezeichnung an. Ich habe gelegentlich Funktionsparameter mit Namen wie b gesehen, weil es ein boolescher Wert ist. isVisible wäre aber doch sehr viel klarer gewesen. Unklare Bezeichnungen bei Methodennamen oder Klassen kann man ebenfalls durch klare Bezeichnungen ersetzen. Hier darf man ja auch gerne mal einen längeren Namen wählen, denn die modernen IDEs unterstützen mich ja beim Programmieren (z.B. Code-Vervollständigung).

      Also was bringt „sparsames kommentieren“. Man macht sich mehr Gedanken über den Code den man schreibt. Darüber ob Variablen klar benannt sind, wie die Struktur eines Algorithmus aussieht („Premature optimization …“) und wie meine Methoden und Klassen heißen. Wenn ich das alles beachte und der Code noch unklar ist, dann schreibe ich einen Kommentar 🙂

  2. Habe das Buch vor einiger Zeit auch gelesen und ich mag es wirklich. Ich finde es ist noch ein bisschen mehr Praxisbezogen als Clean Code, bzw hat gute prägnante kurze Beispiele.

    5 Sterne 🙂

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.