Clean Code für Dummies

Jürgen Lampe

• Verlag: Wiley-VCH
• Jahr: 2020
• ISBN:
  9783527823925
• Auflage: 1
• Thema: Computer Science
• Thema: Software Development

Clean Code ist eine wichtige Methode, um zu besserer Software zu kommen. Zu beachten sind Korrektheit, Verständlichkeit, Lesbarkeit und Ressourcenverbrauch. Programmieren ist aber mehr als ein Handwerk. Klarer Code ist auch Ausdruck klaren Denkens und beginnt damit schon vor der Niederschrift. Regeln sind wichtige Stützen, aber das eigenständige Denken, Entscheiden und Abwägen ersetzen sie nicht. Das Buch vermittelt handwerkliche Fertigkeiten und stellt das Programmieren in den Gesamtprozess der Softwareentwicklung.

Teil III

Sauberen Code schreiben

IN DIESEM TEIL …

• Lernen Sie Regeln und Grundsätze kennen, um Clean Code zu schreiben
• Gestalten Sie Code durch gute Namen und passende Formatierung besser lesbar
• Begreifen Sie Schnittstellen als Schlüssel für eine verständliche Struktur
• Erfahren Sie einiges über den Umgang mit Fehlern und Fehlersituationen
• Lernen Sie neue Sprachelemente zu bewerten und zu nutzen

Kapitel 10

Namen sind nicht Schall und Rauch

IN DIESEM KAPITEL

• Namen sind wichtig für das Vermitteln des Verständnisses
• Gute Namen zu finden, ist nicht einfach
• Woran Sie gute Namen erkennen können
• Die Qual der Sprachwahl

In diesem Kapitel dreht sich alles um Namen. Was zeichnet gute Namen aus? Welche Fehler sollten Sie vermeiden und wie lassen sich treffende Bezeichnungen finden? Abschließend werden einige Gesichtspunkte, die bei der Wahl der Sprache bedeutsam sind, betrachtet.

Benennungen

Wenn Goethe seinen Doktor Faust »Name ist Schall und Rauch« sagen lässt, drückt der sich nicht nur um die Antwort auf die berühmte Gretchenfrage, sondern verweist darauf, dass Benennungen letztlich immer willkürlich sind. Trotzdem spielen sie eine unverzichtbare Rolle in der menschlichen Kommunikation.

Ohne die Übereinkunft, einen Sachverhalt mit einem bestimmten Namen zu bezeichnen, kann es keinen Austausch von Informationen geben. Je besser dabei die jeweiligen Interpretationen von Sprecher und Hörer beziehungsweise von Sender und Empfänger übereinstimmen, desto effektiver und leichter ist die Verständigung.

Auch wenn das gern übersehen wird, ist Code in ganz erheblichem Umfang ein Verständigungsmittel zwischen Menschen, und zwar zwischen denjenigen, die ihn schreiben, und denen, die ihn lesen und verstehen wollen. (Das müssen bei größerem zeitlichem Abstand nicht unbedingt verschiedene Personen sein.)

Deshalb war es nur logisch, dass einer der ersten Schritte nach der Erfindung des Computers darin bestand, die kryptischen Zahlenfolgen der frühen Programme durch sogenannte mnemotechnische Codes etwas lesbarer zu machen. Statt der Zahlenfolge 0500020 konnte man dann beispielsweise ADD 20 schreiben, um den Inhalt der Speicherzelle 20 zum Inhalt des Akkumulatorregisters zu addieren.

In der Programmierung haben Namen allerdings nie die ihnen gebührende Aufmerksamkeit gefunden. Bis heute werden Sie in der Literatur fast nichts darüber finden, wie Sie effektiv zu ausdrucksstarken Namen kommen können. Clean Code betont zwar immerhin die Wichtigkeit guter Bezeichnungen, hält aber, wenn es darum geht, solche zu finden, auch keine wirkliche Hilfe bereit. Das ist schade, denn es handelt sich um ein Kernprinzip, das alles andere als einfach umzusetzen ist.

Namen versus Bezeichner

In der Informatik spricht man statt von Namen häufig auch von Bezeichnern oder Identifikatoren. Gemeint ist damit immer eine bestimmten Regeln folgende Zeichenfolge, die ein an sich abstraktes Element eines Programms möglichst eindeutig identifiziert. Ich habe dabei ganz bewusst den Begriff »Zeichenfolge« und nicht »Wort« gewählt, weil das lange die vorherrschende Sicht auf Namen war und in einigen Bereichen notwendigerweise immer noch ist.

Bezeichner in Programmiersprachen

Da Speicherplatz teuer war, gab es ursprünglich in fast allen Programmiersprachen Längenbeschränkungen für Bezeichner. Üblicherweise waren nur sechs oder acht Zeichen erlaubt, bei kleinen Computern auch weniger. Manchmal wurde zwischen Groß- und Kleinbuchstaben unterschieden, manchmal nicht.

Immerhin erlaubten es einige Sprachen, dass im Code längere Bezeichnungen verwendet werden konnten. Allerdings mussten sich diese dann in den »signifikanten« ersten Stellen unterscheiden, weil nur diese vom Compiler oder Interpreter berücksichtigt wurden.

Erst mit Java wurde der Verwendung beliebig langer Bezeichner wirklich zum breiten Durchbruch verholfen. Relikte aus der »guten alten Zeit« können Sie aber noch an vielen Stellen finden, beispielsweise in der Gewohnheit, Abkürzungen durch Weglassen von Vokalen zu gewinnen, etwa List zu Lst oder println für printline.

Namen versus Begriffe

Bei den Bezeichnungen ist darauf zu achten, dass sie für das Erfinden bequem sind. Dies ist am meisten der Fall, so oft sie die innerste Natur der Sache mit Wenigem ausdrücken und gleichsam abbilden. So wird nämlich auf wunderbare Weise die Denkarbeit vermindert. (G. W. Leibniz)

Wahrscheinlich haben Sie selbst schon öfter bemerkt, dass es vielfach gar kein Problem ist, passende Namen zu finden. Bei anderer Gelegenheit erscheint es dagegen fast unmöglich. Die Ursache für diesen Unterschied lässt sich leicht erklären. Einmal haben Sie es mit Denkstrukturen oder Konzepten zu tun, die nicht nur Ihnen bereits bekannt sind. Im anderen Fall beackern Sie echtes Neuland und haben erste Konzepte oder Begriffe geprägt.

Was Ihnen in dieser Situation noch fehlt, ist ein Name, der dem neuen Begriff Ausdruck verleiht. Wissenschaftler haben es da im Allgemeinen etwas einfacher. Sie nehmen ein ihnen passend erscheinendes Wort (oder eine Phrase) und definieren es als Namen des neuen Begriffs. Von Ihnen als Softwareentwickler wird hingegen erwartet, dass Sie nicht nur den neuen Begriff inhaltlich kreieren, sondern auch noch einen Namen finden, der allen Lesern sofort klarmacht, was Sie damit meinen.

Der Name soll implizit die Definition mitliefern. Das wird Ihnen nur selten auf Anhieb gut gelingen und zuweilen überhaupt nicht. Angesichts der Schwere dieser Aufgabe sollten Sie jedoch nicht resignieren. Versuchen Sie, so weit zu kommen, wie es geht. Üben hilft, und Sie werden dabei überdies das ursprüngliche Problem besser verstehen lernen.

• 
  Diskutieren Sie im Team die zu benennenden Konzepte.
• Benutzen Sie Synonymverzeichnisse und sammeln Sie Vorschläge. Nutzen Sie dabei das Wissen derjenigen, die mit dem Anwendungsgebiet vertraut sind.
• Versuchen Sie, den neuen Begriff zu definieren – selbst wenn Sie noch keinen Namen dafür haben.
• Versuchen Sie, das Konzept einem völlig unbeteiligten Menschen zu erklären. Benutzen Sie dabei Analogien. Das kann der Suche nützliche Impulse geben.
• Wenn Sie sich für einen Vorschlag entschieden haben, verwenden Sie diesen konsequent in allen Dokumenten.
• Konsequent sein heißt allerdings nicht, dass Sie einen Namen nicht später durch einen besseren ersetzen sollten.

Gerade zu Beginn eines Projekts werden Sie häufig feststellen, dass eine gewählte Bezeichnung doch nicht so gut passt. Das ist natürlich und der Weg der Erkenntnis. Vermeiden Sie aber um jeden Preis, dass der alte, schlechtere Name noch irgendwo erhalten bleibt. Nichts ist verwirrender als Code, bei dem man anhand der verwendeten Namen erkennen kann, in welcher Projektphase er entstanden ist. Ein unbefangener Leser kennt die Entstehungsgeschichte ja nicht und wird durch die unterschiedlichen Namen irritiert.

Selbstverständli...

Inhaltsverzeichnis

• Cover
• Inhaltsverzeichnis
• Über den Autor
• Einleitung
• Teil I: Das Clean-Code-Prinzip
• Teil II: An Herausforderungen wachsen
• Teil III: Sauberen Code schreiben
• Teil IV: Wege zum Ziel
• Teil V: Der Top-Ten-Teil
• Stichwortverzeichnis
• End User License Agreement