Das Clean Programmer Manifest oder Robert Martins Short Code Book Summary

Dieser Artikel ist eine Zusammenfassung von Robert Martins Clean Code-Buch und meinem Verständnis, wie Clean Code sein sollte. Es gibt keine Abschnitte über Testen, TDD, welche Architektur usw. sein sollte. Hier dreht sich alles darum, was der Clean Code sein sollte.

Ja, vielleicht ist das Thema Clean Code bereits abgedroschen, aber dennoch ist nicht jeder damit vertraut, und außerdem habe ich keine Analoga des Inhalts getroffen, der in meinem Artikel enthalten ist.

Allgemein

Es gibt keinen wahren Weg und keine Lösung. Es gibt eine, die für eine bestimmte Aufgabe am besten geeignet ist.

Versuchen Sie bei der Lösung eines Problems, absolut alle Fälle zu reproduzieren, die diese Aufgabe betreffen könnten, und implementieren Sie die Aufgabe unter Berücksichtigung absolut aller Fälle.

Versuchen Sie bei der Lösung des Problems auch, das Gegenteil zu tun. Verstehen Sie, welche Art von Ergebnissen Sie am Ende erzielen möchten, und legen Sie auf dieser Grundlage den Algorithmus fest, mit dem die Aufgabe ausgeführt wird.

Überprüfen Sie vor dem Senden einer Aufgabe zur Freigabe, ob sie ordnungsgemäß funktioniert. Gibt es irgendwelche Fehler darin. Dies gilt auch für die Commits, die an Ihre Niederlassung gesendet werden. Das idealste Szenario ist eines, in dem niemand Fehler in der von Ihnen entwickelten Funktionalität finden kann.

Denken Sie immer daran, wie Sie Ihren Code einfacher, sauberer und lesbarer machen können.

• Welche Fälle kann eine Aufgabe haben?
• Habe ich alles berücksichtigt?
• Was könnte schief gehen?
• Was kann kombiniert werden?
• Gibt es ähnliche Funktionen?
• Was ist hier überflüssig?
• Wie macht man es einfacher?
• Wie macht man es lesbarer?
• Wie kann man es klarer machen?

Code bereinigen

Wie schreibe ich sauberen und guten Code? Es ist wie ein Buch zu schreiben. Zuerst machen Sie einen Entwurf und kämmen ihn dann in den Zustand, in dem Sie ihn gerne lesen würden. Denken Sie immer daran, dass Ihr Code eine Geschichte erzählen muss, damit der Leser sie verstehen kann.

Eine Entität wird verstanden - eine Schnittstelle, eine Klasse, eine Methode, eine Variable, ein Objekt usw.

• Sauberer Code ist einfach, ausdrucksstark und auf eine bestimmte Aufgabe ausgerichtet.
• Sauberer Code ist leicht zu lesen, wie Prosa. Ist dies nicht der Fall, lohnt sich eine Umgestaltung.
• Clean Code ist einfach zu ändern. Es sollte nicht starr an einen Haufen von Entitäten gebunden sein. Jede Entität kann leicht geändert werden.
• Sauberer Code durchläuft eine Überprüfung viel besser. Wenn die Überprüfung viele Kommentare enthält, ist sie nicht sauber und muss überarbeitet werden.
• Sauberer Code sieht immer so aus, als ob er schon sehr lange bearbeitet wurde. Unabhängig davon, wie Sie es verbessern möchten, werden Sie dennoch zu dem Schluss kommen, dass dieser Code der beste ist. Dementsprechend wird sauberer Code bis ins kleinste Detail durchdacht.
• Pfadfinderregel: Lassen Sie den Parkplatz sauberer als vor Ihnen. Dies wechselt leicht zur Programmierung. Sehen Sie den schmutzigen Code? Machen Sie es sauberer, während Sie Ihr Problem lösen. Sie sollten sich davon nicht mitreißen lassen, und wenn der schmutzige Code sehr schmutzig ist, sollten Sie eine separate Aufgabe und Zeit für die Reinigung zuweisen.
• Haben Sie keine Angst, Änderungen vorzunehmen. Wenn Sie sie erstellen möchten, haben Sie Gründe dafür, was bedeutet, dass Sie den Code besser und sauberer machen. Darüber hinaus zeigen Tests, ob Ihr Code Fehler enthält (sofern diese überhaupt vorhanden sind).
• Jedes Unternehmen sollte für eine Funktion und nur für diese verantwortlich sein. Und sie muss es gut machen. Einzelverantwortung.
• Wenn eine Entität sofort für zwei oder mehr Aktionen verantwortlich ist, muss ihre Funktionalität getrennt werden.
• Der Code sollte von oben nach unten gelesen werden.
• In einer guten und kompetenten Architektur können Änderungen ohne nennenswerte Kosten und Aufwand vorgenommen werden.
• Toten Code löschen. Ein toter Code ist ein Code, der unter keinen Umständen aufgerufen wird, oder ein Code, der nirgendwo verwendet wird.

Namen und Abteilungen

• Verwenden Sie für alle Entitäten klare und leicht auszusprechende Namen. Sie sollten beschreiben, warum diese Entität existiert, was sie tut und wie sie verwendet wird.
• Haben Sie keine Angst, Zeit damit zu verschwenden, den besten und freundlichsten Namen zu wählen. Sie werden in Zukunft gewinnen, wenn Sie diesen Code bearbeiten oder lesen.
• Wenn der Name der Entität nicht ihrer Funktionalität entspricht oder der Name nicht versteht, was die Entität tut, muss sie in den verständlichsten Namen umbenannt werden. Wenn dies nicht möglich ist, stimmt etwas mit seiner Funktion nicht und es muss überarbeitet werden.
• Die Entität, die den Namen "And", "With" trägt, verstößt gegen die Einzelverantwortung. Die Funktionalität einer solchen Entität ist es wert, geteilt zu werden. Aber diese Regel wird manchmal vernachlässigt.
• Unverständliche Texte, Zeilen sollten in Variablen aufgenommen und ihnen klare Namen gegeben werden.
• Methodennamen müssen ein Verb enthalten, das beschreibt, was diese Methode tut und mit welchem ​​Schlüsselwort diese Methode arbeitet. Wenn der Name der Methode kein Verb enthält, sollte diese Entität keine Methode sein oder den richtigen Namen erhalten.
• Dieselben Namen sollten aus zwei verschiedenen Gründen vermieden werden.
• Wenn eine Entität einen ähnlichen Namen wie eine andere Entität hat, ist ihre Funktionalität höchstwahrscheinlich sehr ähnlich und sie müssen kombiniert werden? Wenn nicht, müssen ihre Namen geändert werden, damit sie nicht ähnlich sind.
• Wenn Sie eine Entität beim Lesen des Codes mental umbenennen, damit Sie ihre Funktionalität besser verstehen können, benennen Sie sie in diesen mentalen Namen um.
• Wählen Sie ein Wort für ein Konzept. Es wird schwierig sein, die Funktionalität zu verstehen, wenn Sie die Namen abrufen, abrufen und eingeben. Besser überall hinkommen.
• Ein langer und verständlicher Name ist besser als ein kurzer, aber unverständlicher.

Funktionen

• Funktionen sollten kurz und kompakt sein.
• Funktionen sollten sehr kurz und sehr kompakt sein.
• Maximal 20 Zeilen und 150 Zeichen in einer Zeile. Wenn es nicht passt, müssen Sie es trennen.
• Eine Funktion darf nur eine Operation ausführen.
  
  • Sie muss es gut machen und sie sollte nichts anderes tun.
  • Wenn eine Funktion nur die Aktionen ausführt, die sich auf derselben Abstraktionsebene befinden, führt die Funktion eine Operation aus.
  • Um festzustellen, ob eine Funktion mehr als eine Operation ausführt, extrahieren Sie eine andere Funktion daraus. Dies ist keine einfache Neuformulierung der Implementierung.
• Alle bedingten Anweisungen mit langen Auswahlmöglichkeiten über switch-case, if-else sollten ohne Duplizierung aufgeteilt oder kombiniert werden, möglicherweise in Klassen mit Implementierungen, und die Auswahl der Implementierung an die Basisklasse, die Factory oder eine andere Person übertragen.
• Wenn, sonst, während usw. muss einen Aufruf einer Funktion enthalten. Es wird lesbarer, klarer und einfacher.
• Die ideale Anzahl von Eingabeargumenten für eine Funktion ist = 0. Wenn mehr als drei Eingabeargumente vorhanden sind, sollten Sie überlegen, wie Sie diese entfernen können. Erstellen Sie beispielsweise eine Klasse für diese Argumente.
• Je mehr Eingabeargumente vorhanden sind, desto schwieriger wird die Funktion verstanden.
• Die Funktion, an die das Argumentargument übergeben wird, von der die Operation der Funktion abhängt, gibt an, dass die Funktion mehr als eine Operation ausführt. Solche Funktionen sollten in zwei Teile geteilt und eine höhere Ebene genannt werden.
• Eine Funktion, die das Eingabeargument ändert, muss einen Verweis auf das geänderte Objekt geben und darf es nicht nur ändern, ohne zurückzukehren. String transform(String text)
• Wenn die Funktion das Eingabeargument ändern muss, lassen Sie sie den Status ihres Eigentümerobjekts ändern.
• Wenn sich das Eingabeargument der Funktion nicht ändern soll (und im Code weiter verwendet wird), sollten Sie den Wert des Arguments kopieren und mit der Kopie innerhalb der Funktion arbeiten.
• Anstatt null zurückzugeben, ist es besser, ein leeres Objekt - Collection.empty() oder ein Nullobjekt - EmptyObject() .
• Versuchen Sie immer, nicht statische Funktionen zu verwenden. Wenn dies nicht möglich ist, verwenden Sie static.
• Wenn es einen Code gibt, der nacheinander folgen soll, übergeben Sie die Ergebnisse der ersten Funktion an die zweite, damit die Reihenfolge der Aufrufe nicht geändert wird.
• Verwenden Sie Polymorphismus anstelle von if / else oder switch / case oder when.
• Vermeiden Sie negative Bedingungen.

Kommentare

• Verwenden Sie keine Kommentare, wenn Sie stattdessen eine Funktion oder Variable verwenden können.
• Kommentieren Sie den fehlerhaften Code nicht - schreiben Sie ihn neu. Es lohnt sich nicht zu erklären, was in schlechtem Code passiert. Es ist besser, ihn explizit und verständlich zu machen.
• Kommentare können verwendet werden, um einige Informationen und Warnungen über die Folgen zu übermitteln, aber nicht um zu erklären, wie der Code funktioniert.
• Verwenden Sie TODO und FIXME in Fällen, in denen Sie beachten müssen, dass der Code verbessert werden muss, aber jetzt keine Ressourcen dafür vorhanden sind.
• Verwenden Sie //region REGIONNAME //endregion REGIONNAME . Wenn Sie verwenden, //region REGIONNAME //endregion REGIONNAME Sie, ob es möglich ist, die Region in Entitäten zu unterteilen.
• Dokumentcode, der komplex, aber sauber ist.
• Lassen Sie den alten auskommentierten Code nicht. Sie finden es bei Bedarf im Commit-Verlauf.
• Kommentare sollten präzise und klar sein. Informationskommentare sollten nicht viele Informationen enthalten. Alles sollte kurz und auf den Punkt sein.

Formatierung und Regeln

• Befolgen Sie den im Projekt festgelegten Codestil.
• Befolgen Sie die im Team akzeptierten Regeln.
• Abhängig von Formatierung und Codestyle ist der Code leichter zu lesen und besser. Es ist nicht umsonst, dass das Buch dem Herausgeber vor der Veröffentlichung übergeben wird.
• Sie benötigen automatische Tools, die den Code für Sie formatieren.
• Die Quelldatei sollte wie ein Zeitungsartikel sein. Es gibt eine Überschrift, eine kurze Beschreibung in Form von Parametern und Inhalte in Form von Funktionen. Ist dies nicht der Fall, sollten Sie die Formatierung ändern.
• Entitäten, die miteinander in Beziehung stehen, sollten sich beispielsweise in einem Paket befinden, damit die Navigation durch den Code einfacher ist.
• Klassenvariablen (Felder) müssen sich oben in der Klasse befinden.
• Methodenvariablen sollten näher an ihrem Verwendungsort liegen.
• Funktionen müssen in der Reihenfolge des Aufrufs sein. Wenn einer den anderen aufruft, muss die aufrufende Funktion über der aufgerufenen liegen. Auf der anderen Seite befinden sich private Funktionen auf niedrigerer Ebene möglicherweise am Ende der Datei und beeinträchtigen das Verständnis von Code auf hoher Ebene nicht. Aber ich bevorzuge den ersten Weg.

Objekte und Datenstrukturen

• Sie müssen mit Abstraktionen arbeiten, damit die Implementierung leicht geändert werden kann.
• Sie sollten mit Abstraktionen arbeiten, da der Client, der die Funktionalität verwendet, die Implementierungsdetails nicht kennen sollte und wissen sollte, welche Implementierung in welchem ​​Fall verwendet werden soll.
• Sie müssen eine API bereitstellen, mit der Sie arbeiten sollten, und Implementierungsdetails und -struktur ausblenden. So wird es einfacher, mit solchen Entitäten zu arbeiten und neue Verhaltensweisen, Funktionen und Implementierungen hinzuzufügen.
• DTO - Datenübertragungsobjekt. Eine Klasse, die nur Daten und keine Funktionalität enthält. Es ist notwendig, um einige Daten zu übertragen. Ein Objekt dieser Klasse muss unveränderlich sein.

Klassen

• Der Unterricht muss kompakt sein.
• Der Unterricht sollte noch kompakter sein.
• Der Name der Klasse sollte ihre Verantwortung beschreiben. Von hier aus können Sie die Größe der Klasse berechnen.
• Die Funktion der Klasse muss eindeutig übereinstimmen und in den Namen der Klasse passen.
• Teilen Sie die Verbundenheit in kleine Klassen. Es sollte keinen starren und reichlichen Zusammenhalt geben - dies erschwert die Unterstützung und Entwicklung des Projekts.
• Denken Sie an die Einzelverantwortung. Eine Entität muss nur einen Grund für eine Änderung haben.
• Verkapselung beobachten. Die Schwächung der Kapselung sollte immer das letzte Mittel sein.
• Normalerweise deklarieren wir Variablen und Hilfsfunktionen als privat, aber manchmal müssen sie als geschützt deklariert werden und können vom Test aus darauf zugreifen können.
• Wenn eine Gruppe von Funktionen zu einer bestimmten Funktion gehört, kann und sollte diese Gruppe von Funktionen einer separaten Klasse zugewiesen werden und ihre Instanz verwenden.

Fehlerbehandlung

• Verwenden Sie Ausnahmen, anstatt Fehlercodes zurückzugeben.
• Die Fehlerbehandlung ist eine Operation. Wenn die Funktion ein Schlüsselwort try , sollte nach dem Blockieren von catch/finally nichts anderes in der Funktion enthalten sein.
• Wenn Sie eine Aufzählung haben, in der Fehler aufgelistet sind, ist es besser, sie zu entfernen und stattdessen Ausnahmen zu verwenden.
• Verwenden Sie nicht aktivierte Ausnahmen, um den Ort, an dem Probleme auftreten, explizit anzugeben. Solche Fehler müssen nicht abgefangen werden, sondern Sie müssen Code schreiben, damit dieser Fehler niemals auftritt.
• Übergeben Sie genügend Informationen und lösen Sie eine Ausnahme aus, damit Ihre Codebenutzer später verstehen können, was wirklich passiert ist.
• Anstelle von bedingten Anweisungen mit Fehlerbehandlung ist es besser, Ausnahmen auszulösen und zu behandeln.
• Übergeben Sie nirgendwo null. Versuchen Sie dies so weit wie möglich zu vermeiden.
• Die Fehlerbehandlung ist eine separate Aufgabe und gilt nicht für die Hauptlogik des Programms.

Grenzen

• Wir verwenden immer einige Bibliotheken, die uns meistens zu breite, zu kleine Funktionen bieten oder mit der erwarteten Funktionalität in Konflikt stehen, was den Code bei seiner endgültigen Verwendung unübersichtlicher macht. Sie können dies vermeiden, indem Sie einfach Muster wie Decorator, Adapter, Facade oder andere anwenden.
• Es gibt Situationen, in denen Sie mit Funktionen arbeiten müssen, die sich in der Entwicklung befinden oder noch nicht für die Verwendung im Produktionscode angepasst wurden. In diesem Fall sollten Sie sich vorstellen, was Sie von der Bibliothek / dieser Funktionalität erwarten, und Ihre Schnittstelle schreiben oder eine Entität erstellen, mit der Sie in Ihrem Projekt so arbeiten, wie Sie es benötigen. Wenn die Bibliothek fertig ist und stabil ist, passen Sie sie an Ihre vorgefertigten Strukturen an und verwenden vorgefertigte Funktionen.

Nachwort

Dieser Artikel enthält nur Richtlinien zum Schreiben eines Clean Codes. Natürlich können sie vernachlässigt werden. Sie müssen nur verstehen, dass jede Ihrer Entscheidungen Argumente dafür haben sollte.