Scheiße schlechter Code, gefällt dir das?

Es gibt ein Projekt auf GitHub, das neunzehn Schlüsselprinzipien für den „besten Müllcode“ beschreibt. Von der Variablenbenennung bis zum Schreiben von Kommentaren. Diese Richtlinien helfen Ihnen dabei, den bestmöglichen schlechten Code zu schreiben.

Um den gleichen Stil wie das ursprüngliche GitHub-Projekt beizubehalten, wurde Folgendes nicht konvertiert. Der Leser kann alle Standpunkte aus der entgegengesetzten Perspektive verstehen, was eine perfekte Möglichkeit ist, das Schreiben von Müllcode zu vermeiden.

Projektadresse:
https://github.com/trekhleb/state-of-the-art-shitcode

Natürlich sind die folgenden neunzehn Richtlinien zum Schreiben von Müllcode nicht erschöpfend Sie können auch Ihre Meinung zu einigen unerträglich schlechten Programmiergewohnheiten äußern.

? Artikel 1: Je weniger tippen, desto besser

Wenn wir weniger tippen, haben wir mehr Zeit, über Codelogik und andere Probleme nachzudenken. Wie unten gezeigt, bezeichnet „Gut“ Beispiele, die der Regel folgen, und „Schlecht“ kennzeichnet Beispiele, die der Regel nicht folgen.

Artikel 2: Gemischter Benennungsstil von Variablen/Funktionen

Wir müssen Benennungsmethoden und Variablen kombinieren, um die Vielfalt der Benennung widerzuspiegeln.

? Artikel 3: Keine Kommentare schreiben

Du kannst den Code trotzdem verstehen, warum solltest du Kommentare schreiben? Mit anderen Worten: Meinen Code liest sowieso niemand, warum sollte ich also Kommentare schreiben?

? Regel 4: Schreibe Kommentare in deiner Muttersprache

Wenn du gegen Regel 3 verstößt, dann schreibe zumindest Kommentare in deiner Muttersprache oder einer anderen Sprache. Wenn Sie Englisch als Muttersprache sprechen, verstoßen Sie ebenfalls gegen diese Regel. Da die überwiegende Mehrheit der Programmiersprachen auf Englisch ist, warum nicht auch in anderen Sprachen kommentieren?

? Artikel 5: Möglichst verschiedene Formate mischen

Auch hier müssen wir für die Codevielfalt so weit wie möglich verschiedene Formate wie einfache oder doppelte Anführungszeichen mischen. Wenn sie die gleiche Semantik haben, sollten sie gemischt werden.

? Artikel 6: Schreiben Sie den Code so weit wie möglich in eine Zeile

Wenn eine Reihe von Parametern und Methoden zusammen implementiert werden, sollte der Code auch zusammen geschrieben werden.

?Artikel 7: Schweigen Sie, wenn Sie Fehler finden

Wenn Sie einige Fehler finden, müssen andere nichts davon wissen, sodass Sie das Protokoll nicht ausdrucken müssen oder Rückverfolgung.

?Artikel 8: Globale Variablen umfassend nutzen

Die Verwendung globaler Variablen ist ein unverzichtbarer Bestandteil der Bewältigung der „Globalisierung“.

? Punkt 9: Backup-Variablen erstellen

Für alle Fälle müssen wir einige Backup-Variablen erstellen und diese bei Bedarf jederzeit aufrufen.

?Artikel 10: Der Typ muss mit Vorsicht verwendet werden

Geben Sie im Allgemeinen keine Variablentypen an und führen Sie keine häufigen Typprüfungen durch. Kein Typ ist der beste Typ.

? Artikel 11: „Plan B“ vorbereiten

Sie müssen einen nicht erreichbaren Code (nicht erreichbarer Code) vorbereiten, der als Ihr „Plan B“ verwendet werden kann.

?Artikel 12: Verschachtelte Dreiecksregel

Wenn der Code einige verschachtelte Strukturen oder Strukturen mit eingerückten Leerzeilen enthält, ist die Dreiecksregel die schönste.

?Artikel 13: Gemischte Einrückung

Wir müssen die Verwendung von Einrückungen vermeiden, da durch Einrückungen komplexer Code mehr Platz im Editor einnimmt. Wenn Sie Einrückungen verwenden müssen, verwenden Sie eine gemischte Einrückungsstrategie. Natürlich funktioniert diese Strategie nicht in Python, das zur Strukturierung seines Codes auf Einrückungen angewiesen ist.

?Artikel 14: Abhängigkeiten nicht sperren

Aktualisieren Sie jedes Mal, wenn Sie eine neue Bibliothek installieren möchten, vorhandene Abhängigkeiten. Warum die vorherige Version beibehalten? Wir müssen jederzeit die neueste Codebasis von Drittanbietern beibehalten.

?Artikel 15: Lange Funktionen sind besser als kurze Funktionen

Teilen Sie die Gesamtlogik des Programms nicht in einige Codeblöcke auf, da die IDE die erforderlichen Dateien nicht finden kann oder Funktionen, was zu tun ist. Daher ist es die stabilste Methode, den Code in einer Hauptfunktion zu schreiben und keine zusätzlichen Funktionsimporte oder Codedateien mehr zu pflegen.

Eine einzelne Datei mit 10.000 Zeilen Code ist kein Problem, und eine einzelne Funktion mit tausend Zeilen Code ist kein Problem.

?Artikel 16: Der Code erfordert keine spezifischen Tests

Diese Tests sind normalerweise repetitive und bedeutungslose Arbeiten.

? Artikel 17: Versuchen Sie, Codeduplizierungen zu vermeiden

Schreiben Sie Code nach Ihren Vorstellungen, insbesondere in einem kleinen Team, schließlich ist dies das Prinzip der „Freiheit“.

?Artikel 18: Zum Erstellen eines neuen Projekts ist kein README-Dokument erforderlich

In der Anfangsphase des Projekts können wir diesen Zustand vorübergehend beibehalten.

?Artikel 19: Unnötigen Code speichern

Beim Schreiben von Code wird häufig viel Testcode generiert. Da es sich bei diesen Codes ebenfalls um sehr wichtige Informationen handelt, können sie nicht gelöscht und höchstens auskommentiert werden.

Das obige ist der detaillierte Inhalt vonScheiße schlechter Code, gefällt dir das?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!