Überlegungen zu Schönheit und Code

Ich denke, dass früher oder später jeder Entwickler in seinem Kopf denkt, dass der Code auf eine bestimmte Weise geschrieben werden muss. Warum ist das Framework dieses Autors so einfach zu verwenden und das Eintauchen in es ist so schnell? Warum erscheint mir dieser Code schrecklich? In diesem Moment findet eine wichtige Runde in der Entwicklung des Entwicklers als Profi statt. Er beginnt nicht nur darüber nachzudenken, wie eine bestimmte Aufgabe umgesetzt werden soll, sondern auch, wie er seine Entscheidung formalisieren kann . In meinem Kopf tauchen Gedanken über eine bestimmte Strukturierung des Codes und sein schönes Design auf. Jemand beginnt für sich selbst ein bestimmtes empirisches Regelwerk für die Gestaltung des Codes zu erstellen, jemand hilft der Literatur oder dem Rat erfahrener Kameraden. In jedem dieser Szenarien wird der Code nicht nur als bedingungslose Lösung des Problems angesehen. Es gibt Gedanken, dass ein Teil des Codes hässlich gemacht wurde , aber hier stellte sich heraus, dass es cool und elegant war . Aber wer definiert diese Schönheitskriterien in Bezug auf den Code und was ist darin enthalten? Ist alles klar über Code-Etikette und Schönheit?

Haftungsausschluss: Dieser Artikel zielt darauf ab, Gedanken auszutauschen, die bei dem Versuch entstanden sind, das Konzept des schönen Codes zu verstehen. Diese Gedanken behaupten nicht, die ultimative Wahrheit zu sein. Ich hoffe nur, dass diese Gedanken, Gedanken und Argumente wahrscheinlich jemandem helfen werden, den Prozess des Schreibens von Code aus einer etwas anderen Perspektive zu betrachten. Ferner keine einzige formale Regel der Form "Schreiben Sie den Code auf diese Weise, und Sie werden glücklich sein." Zu diesem Thema wurde bereits eine große Menge Literatur von viel angeseheneren Autoren verfasst.

Alle, die an Diskussionen über das Thema interessiert sind, was Code-Schönheit ist, worin sie ausgedrückt werden kann, warum alle bekannten Praktiken diese Frage nicht ein für alle Mal schließen können, bitte ich um Katze.

Gute und schlechte Praktiken

"... und fragte das Baby: - ​​Was ist gut und was ist schlecht?" - Mayakovsky V.V.

Und wir fragen uns oft, wie wir unseren Code richtig formatieren können. Um diese Frage zu beantworten, wurde bereits eine große Menge an Fachliteratur in der Welt geschrieben. Nehmen wir zum Beispiel die beliebtesten Werke zu diesem Thema, die am häufigsten gehört werden:

• Sauberer Code - Robert C. Martin
• Perfekter Code. Meisterklasse - Steve McConnell
• Rezeptionen der objektorientierten Programmierung. Design Patterns - Viererbande
• Der pragmatische Programmierer. Die Reise vom Lehrling zum Meister - Andrew Hunt, David Thomas

Ich denke, es gibt eine große Anzahl von Büchern, die diese Liste ergänzen können. In der Geschichte geht es jedoch nicht um die Notwendigkeit, diesen oder jenen Ansatz anzuwenden. Nicht darüber, wie dieses oder jenes Buch gut oder schlecht ist. Im Verlauf der Überlegungen können wir den Schluss ziehen, dass selbst die Verwendung aller in diesen Büchern beschriebenen bewährten Methoden keinen schönen Code garantiert. Und das alles kann sowohl zum Nachteil als auch zum Guten sein. Es stellt sich heraus, dass es sich vielleicht lohnt, zumindest mit einer Skizze von Gedanken darüber zu beginnen, was genau Sie erreichen möchten, wenn Sie versuchen, schönen Code zu schreiben, wenn es keine definitive „Erfolgsformel“ gibt. Wir wissen, was Code ist, aber keiner von uns kann sagen, was schöner Code ist.

Voraussetzungen für Gedanken

Egal wie jemand die Programmierung in eine separate unabhängige Disziplin aufteilen möchte, es kommt auf das Engineering an. Dementsprechend gelten allgemeine Gedanken und Ideen auf dem Gebiet des Ingenieurwesens sowohl für die Automobilindustrie und das Baugewerbe als auch für die Programmierung. Bei all dem geht es um die Anwendung wissenschaftlicher Erkenntnisse auf die Schaffung von etwas Praktischem, zum Teil Materialem (wenn es sich um Softwareentwicklung handelt, können rein philosophische Streitigkeiten über Materialität entstehen). Aus praktischer Sicht gilt: Je einfacher das System (Design, Idee) - desto bequemer, einfacher zu bearbeiten und zu warten und desto schöner erscheint es.




Es gibt viele ähnliche Beispiele aus dem menschlichen Leben und der Natur, die durch einen gemeinsamen Gedanken vereint werden: Oft ist eine einfache Lösung die schönste. In dem Moment, in dem ich herausfinde, wie einfach dieses oder jenes Objekt im Leben so notwendig zu sein scheint, schleicht sich der Gedanke, dass es schön gemacht ist, in meinen Kopf. Während wir nicht über Ästhetik sprechen, sondern ausschließlich über das Gerät „Motorraum“.

Ich bin einmal auf das Buch Kevlin Henney gestoßen - 97 Dinge, die jeder Programmierer wissen sollte: Kollektive Weisheit von Experten . Dieses Buch besteht aus 97 kleinen Kapiteln, die von verschiedenen Personen geschrieben wurden und sich nur auf die Tatsache beziehen, dass es nur um Programmierung geht. Eine Art weltliche Weisheit von Menschen mit umfassender Programmiererfahrung. Machen Sie sofort einen Vorbehalt, dass eine derart detaillierte Beschreibung keinesfalls eine Werbung ist. Aber ich kann dieses Buch nicht erwähnen, da in einem seiner Kapitel der Gedanke gefordert wird, dass schöner Code einfacher Code ist . Im Allgemeinen heißt es „Schönheit liegt in der Einfachheit“ (Schönheit liegt in der Einfachheit). Der Autor beginnt das Kapitel mit einem Zitat von Platon, dass alle schönen Dinge einfach sind:

Schönheit des Stils und der Harmonie und Anmut und des guten Rhythmus hängen von der Einfachheit ab - Plato

Es war dieser Aphorismus, der mein Interesse am Bereich des schönen Codes und die Anwendbarkeit des Konzepts einer „schönen Lösung“ auf den Code und damit die Gleichwertigkeit eines schönen Codes mit dem einfachen Code weiter geweckt hat.

Was ist Schönheit?

Wir kommen also zu der Frage nach der Schönheit des Codes. Um so objektiv wie möglich zu verstehen, ob Schönheit in unserer Frage ein Synonym für Einfachheit ist, sollten wir mit einem Grundkonzept beginnen. Eine Definition finden Sie in Wikipedia:

Schönheit ist eine ästhetische Kategorie, die Perfektion bezeichnet, eine harmonische Kombination von Aspekten eines Objekts, in der letzteres beim Betrachter ästhetisches Vergnügen hervorruft.

Apropos Code, wir können nicht ausschließlich aus ästhetischer Sicht argumentieren. Ein schöner (perfekter, guter) Code kombiniert sowohl Ästhetik als auch Semantik. Die Semantik des Codes sollte auch zur Kategorie der „schönen Lösungen“ gehören.

Ich denke, viele werden zustimmen, dass der Code (genauer gesagt das Ergebnis seiner Arbeit und des Erstellungsprozesses) neben dem praktischen Wert auch kreativ ist. Die engste kreative Analogie zur Softwareentwicklung ist die Schaffung eines literarischen Werks. Diese Zweige der Kreativität haben zweifellos viel gemeinsam. Der Einfachheit halber kann der Programmcode mit einem Buch verglichen werden. Beide sind Simulacrum von Gedanken. Der einzige Unterschied besteht darin, dass das Ergebnis des Codes grob gesagt eine Art Ergebnis auf dem Bildschirm des Geräts ist und das Ergebnis des Lesens des Buches Halluzinationen, visuelle Serien, Assoziationen und Eindrücke sind, die in unseren Köpfen entstehen. Beim Schreiben von Büchern wird eine Vielzahl von Regeln berücksichtigt, mit denen Sie den Text korrekt formatieren können. Dieser Moment ähnelt den Regeln einer Programmiersprache und dem Compiler / Übersetzer / Interpreter-Workflow. Der Quelltext des Buches wird einer strengen iterativen Bearbeitung unterzogen, bevor er vor den Augen des Lesers erscheint. Aber der Inhalt ist wichtiger. Auf der anderen Seite können nur wenige Menschen das interessanteste und faszinierendste Buch bis zum Ende beherrschen oder richtig verstehen, wenn die Gedanken nicht richtig (gelesen: schön) in einem zusammenhängenden Text umrahmt sind.

Warum ist schöner Code wichtig?

Beim Ausdruck von Gedanken auf Papier lohnt es sich zweifellos, sich auf die Regeln der Sprache sowie auf die Struktur und Einfachheit des Ausdrucks zu konzentrieren. Davon hängen direkt Eindrücke und Gedanken ab, die an den Leser weitergegeben werden und welche Bilder in seinem Kopf erscheinen. Der Code ist etwas komplizierter. Dem Endbenutzer unserer Software ist es egal, wie schön sie geschrieben ist und welche Erfahrungen der Entwickler mit der Arbeit mit diesem Code macht. Der Endbenutzer interessiert sich nur für die Qualität des freigegebenen Produkts, wie es funktioniert und wie bequem es zu verwenden ist.

Im Gegensatz zur Literatur ist die Codequalität ein Merkmal, das für den Entwickler oder das Team, das daran arbeitet, wichtig ist. Es müssen keine Entwickler sein. Das gesamte Team (z. B. Projektmanager, Chefs und Investoren) kann während der Entwicklung unter einer Vielzahl von Fehlern leiden. Bei Spezialisten aus anderen Bereichen betrifft die Schönheit des Kodex sie jedoch nur indirekt. Zunächst werden Entwickler Opfer von hässlichem Code. Warum ist es ihnen so wichtig? Die meiste Zeit bei der Entwicklung eines Produkts verbringen wir damit, den Code zu analysieren, darin zu navigieren und nach einem Ort zu suchen, an dem Sie die erforderlichen Zeilen schreiben oder korrigieren müssen.

Alles wäre viel einfacher, wenn eine Person an der Entwicklung eines bestimmten Produkts beteiligt wäre. Der gesamte Quellcode wäre für ihn konsistent und verständlich. Damit genau diese Software in Echtzeit und nicht in Jahrzehnten entwickelt werden kann, ist häufig ein Team von mehreren Entwicklern an der Entwicklung einer Software beteiligt. Es nimmt seine eigenen Anpassungen vor. Zum Beispiel kann das Konzept der Schönheit (insbesondere die Schönheit des Codes) jeder Entwickler sein eigenes haben. Aber da die Arbeit in Teams weitergeht, werden Standards festgelegt, um das Team zum Nachdenken zu bewegen
mehr oder weniger das gleiche. Dies ermöglicht es uns, es so zu gestalten, dass der Entwickler beim Lesen des Codes nicht immer verstehen kann, ob er oder jemand anderes den Code geschrieben hat und wer genau und ein Gefühl der Gemeinschaft, Teamintegrität vermittelt. Wir sagen "Code unserer Anwendung" und nicht "mein Code" oder "mein Skript". Grob gesagt versuchen wir, eine allgemeine Vorstellung von der Schönheit einer Gruppe von Menschen zu bekommen, die durch eine Software verbunden sind, und meistens nichts weiter. Es stellt sich heraus, dass das Konzept der Code-Schönheit Subjektivität enthält, aber wir versuchen, es innerhalb des Teams zu minimieren. Aber ist es möglich, das Konzept der Code-Schönheit vollständig objektiv zu machen? Worauf greifen wir zurück, um objektive Schönheit zu erreichen, und wie viel funktioniert es? Um zur Beantwortung dieser Fragen zu kommen, lohnt es sich, das Wenige zu berücksichtigen, das absolut alle Menschen gemeinsam haben. Nämlich: das Gehirn und wie es Informationen verarbeitet.

Was ist der beste Job des Gehirns?

Im Internet finden Sie unzählige Artikel darüber, wie das Gehirn Informationen erkennt. Sie können beispielsweise auf diesen Artikel verweisen.

Unser Gehirn verarbeitet eine große Menge an Informationen und verwendet zur Optimierung seiner Aktivität Vorlagen. Diese Muster bilden sich im Laufe unseres Lebens. Ein gutes Beispiel ist der Lesevorgang. Je mehr Literatur eine Person in einer Sprache gelesen hat, desto höher ist ihre Lesegeschwindigkeit. Je mehr Bücher Sie lesen, desto mehr Wörter lesen Sie und desto häufiger stoßen Sie auf sie. Die visuelle Erkennung häufig vorkommender Wörter ist um ein Vielfaches schneller als das Lesen neuer Begriffe (insbesondere für einen unbekannten Themenbereich). Je mehr Bücher ein Autor gelesen hat, desto schneller kann er andere Werke dieses Autors lesen. Dies ist wahr, weil jeder Autor einen begrenzten Wortschatz und Schreibstil hat.

Wenn Sie genauer hinschauen, lernen wir, aus der Tatsache zu lesen, dass wir das Alphabet lernen. Genauer gesagt lernen wir, geschriebene Buchstaben zu erkennen, und erst dann nehmen wir die Erkennung von Wörtern auf. Eine weitere interessante Tatsache betrifft die Erkennung von Buchstaben - die Geschwindigkeit der Erkennung von Buchstaben durch das Gehirn hängt auch von der Schriftart ab, wenn es sich um gedruckten Text oder um Handschrift für handgeschriebene Texte handelt. Darüber hinaus kann die Situation bei handgeschriebenen Texten bis zur Absurdität gehen - die Handschrift kann so schlecht sein, dass wir einfach nicht erkennen können, was geschrieben steht (Hallo an die Ärzte). Der Prozess, einem Kind das Lesen beizubringen, ist höchstwahrscheinlich genau das entscheidende Phänomen, das die Menschen dazu inspiriert hat, neuronale Netze zu entwickeln. Wer sich für dieses Thema interessiert, kann sich Materialien ansehen, wie Text mithilfe neuronaler Netzwerkalgorithmen erkannt wird.

Wenn wir die Wörter lesen, achten wir erst in der Anfangsphase auf alle Buchstaben. Und sie lehren uns, entsprechend zu lesen - zuerst nach Buchstaben, dann nach Silben und erst dann nach Worten. Es gibt eine interessante Studie, deren These sich selbst beantworten kann:

Laut den Rzelulattas ist der ilseovadny odongo eines unly unquirtiset nicht offen, in Kokons werden die Kürbisse in Solva sofort geröstet. Galvone, hackt und schlägt bkvuy blyu auf msete. In der Vergangenheit konnten die bkuvs in einem vollständig vollbusigen, vollständig zerrissenen Text ohne Brom versiegelt werden. Pichriony Egoto, weil wir nicht jeden einzelnen Kürbis einzeln herstellen, aber alles ist solide.

Und dies ist ein weiterer Beweis dafür, dass das Gehirn mit Mustern arbeitet. Alle neuen Informationen, die wir vom Gehirn erhalten, versuchen auch, vorhandene Vorlagen zu durchlaufen, wobei auf drei Grundprinzipien zurückgegriffen wird:

• Löschen - Wir löschen nicht verwendete eindeutige Informationen (kleinste Vorlage) aus dem Speicher
• Verzerrung - bezieht sich auf die Übertreibung oder Untertreibung von etwas. Zum Beispiel werden in unserem täglichen Leben oft die Wörter "nie", "immer", "nichts", "alle", "alle" verwendet. Wenn Sie darüber nachdenken, dann ist jede Verwendung eines solchen Wortes eine Lüge oder eine Verzerrung von Tatsachen.
• Verallgemeinerung - Alle neuen Informationen versuchen, vom Gehirn auf etwas reduziert zu werden, mit dem es bereits gearbeitet hat. Bei Analogien ist es einfacher, sich zu erinnern und sich zu erinnern.

Aus diesen Fakten geht hervor, dass ein guter Code aus Vorlagen bestehen sollte, damit wir problemlos damit arbeiten können. Eine solche Vorlage kann als allgemeiner Codestil im Entwicklungsteam dienen. Wenn der Einzug im Code für jede Quelldatei oder Zeile darin unterschiedlich ist, ist das Navigieren darin ziemlich schwierig. Eine weitere Vorlage kann ein gängiges Tippprogramm in Bezug auf einen Themenbereich sein (Code in Bezug auf die Domäne). Dies ist richtig, da einige Wörter je nach Kontext unterschiedliche Bedeutungen haben können (ein gutes Beispiel ist das Wort „Bogen“ oder „Burg“).

Aus dem Gegenteil

Nachdem ich über die Vorlagen nachgedacht hatte, überlegte ich, welcher Code am härtesten funktionieren würde. Der Gedanke, den Code zu verschleiern, schoss mir durch den Kopf. Dies geschieht schließlich nur, um anderen Programmierern das Verständnis der internen Funktionsweise Ihres Systems zu erschweren. Darüber hinaus zeigt der verschleierte Code am deutlichsten die Bedeutung der visuellen Wahrnehmung des Codes.

Als Verschleierungsmethode können Sie dieses Set mitbringen:

• Lange und bedeutungslose Namen von Variablen, Klassen, Methoden und Funktionen. Lange Wörter sind nicht nur schwerer zu lesen, Sie haben auch noch nie in Ihrem Leben solche Kombinationen von Buchstaben und Zahlen gesehen.
• , . , , . , . , . , . - , « ».
• , . . , , . . , .

Es stellt sich heraus, dass schöner Code aus einfachen redundanten Wiederholungen erstellt werden sollte . Es gibt sogar ein bekanntes Akronym DRY zu diesem Thema - Wiederholen Sie sich nicht. Trifft dies jedoch immer zu, wenn Sie die Welt weiter betrachten?

Ein gutes Beispiel ist Musik. Sie kann nicht ohne Wiederholung herumkommen. Es ist erwähnenswert, dass es Ausnahmen von dieser Aussage gibt. Das einfachste Beispiel für eine solche Ausnahme sind virtuose Soli. Die Fans erinnern sich an sie, obwohl sie oft keine Wiederholungen enthalten. Aber im Allgemeinen funktioniert die Regel. Wenn Sie sich die Musik ansehen, die immer mehr an Dynamik gewinnt - Rap / Hip-Hop -, können Sie dies am deutlichsten erkennen. Die Minusstruktur besteht fast vollständig aus einfachen, sich kurz wiederholenden Fragmenten, die ihre Schönheit bei weitem nicht immer charakterisieren. Als entartetes Beispiel können wir uns an das Metronom erinnern - niemand wird argumentieren, dass sein gleichmäßiges und monotones Ticken eine ausgezeichnete musikalische Komposition ist.Kann eine Erhöhung der Anzahl von Wiederholungen in der Musik als Optimierung oder Verbesserung angesehen werden? Sie können sich zuerst die klassische Musik ansehen, die voller unerwarteter Bewegungen, einzigartiger Teile und einer kleinen Anzahl von Wiederholungen ist. Der aktuelle Trend ist fast unabhängig vom Genre, die Werke sind kürzer geworden. Sie heißen jetzt Songs und sind strukturell völlig stereotyp - es gibt eine Einführung, einen Refrain, eine einfache Keynote. Wir nehmen diese Komponenten in verschiedenen Variationen und Kombinationen und erhalten eine mehr oder weniger universelle Formel. Solche Werke sind für das Publikum leichter zu "gehen". Aus diesem Grund gibt es viel mehr Kenner der Popmusik als klassische Liebhaber.Sie heißen jetzt Songs und sind strukturell völlig stereotyp - es gibt eine Einführung, einen Refrain, eine einfache Keynote. Wir nehmen diese Komponenten in verschiedenen Variationen und Kombinationen und erhalten eine mehr oder weniger universelle Formel. Solche Werke sind für das Publikum leichter zu "gehen". Deshalb gibt es noch viel mehr Kenner der klassischen Musik Kenner der Popmusik.Sie heißen jetzt Songs und sind strukturell völlig stereotyp - es gibt eine Einführung, einen Refrain, eine einfache Keynote. Wir nehmen diese Komponenten in verschiedenen Variationen und Kombinationen und erhalten eine mehr oder weniger universelle Formel. Solche Werke sind für das Publikum leichter zu "gehen". Deshalb gibt es noch viel mehr Kenner der klassischen Musik Kenner der Popmusik.

Ein weiteres Beispiel für dieses Phänomen der ständigen Wiederholung und Vereinfachung ist die Spielebranche. Das Genre der Casual Games, das sich nahtlos in das Genre der Hyper-Casual-Spiele einfügt, wird immer beliebter. Dies sind Spiele, die darauf abzielen, eine einfache Kette schneller Aktionen zu wiederholen, die durch einen kurzen Zeitraum streng begrenzt sind. Während komplexe variable Spiele und Spiele mit geringer Wiederholung, beispielsweise das Genre der Strategien, derzeit
schwere Zeiten durchlaufen .

Wenn es ein Beispiel für die Inoperabilität des einfachen nicht redundanten Musteransatzes gibt, sollte dieser Ansatz immer für Code funktionieren?

Wie erreicht man einfachen OOP-Code und was kann helfen?

Von dem Moment an, in dem wir in den Beruf eintauchen, komplex und kompliziert, kreisen auf den ersten Blick Prinzipien und Ansätze um uns herum. Hochrangige Spezialisten, unter deren Fittich wir studieren, sprechen über verschiedene Ansätze, Muster und Bücher, die es wert sind, gelesen zu werden, um im Bereich OOP erfolgreich zu sein. Ich denke, die am häufigsten gehörten Wörter sind Designmuster und SOLID . Nicht jedem wird sofort völlig klar, warum dies alles notwendig ist. Aber der allgemeine Punkt ist, schönen und korrekten Code zu schreiben. Und wie hilft uns das und ist es immer so? Alle magischen Muster und Abkürzungen sollen uns lehren, über das Programmieren mit denselben Mustern nachzudenken wie beim Lesen und Analysieren von einfachem Text.

Sind Designmuster immer gut?

Entwicklern wurden von Anfang an Muster beigebracht. Versuchen wir herauszufinden, warum. Jedes Entwurfsmuster zielt darauf ab, das Objekt so kompakt wie möglich und einfach zu gestalten. Sie tat nicht das, was sie nicht sollte und tat das, was von ihr verlangt wurde, auf die prägnanteste Weise. Bei all dem geht es nicht nur darum, die Lösung architektonisch nachhaltig zu machen, sondern auch darum, die Lösung leicht verständlich zu machen. Von Projekt zu Projekt verwenden Sie ungefähr die gleichen Muster. Die häufige Wiederholung dieser Muster beschleunigt den Entwurfsprozess und die Verarbeitung von vorhandenem Code im Gehirn und reduziert die Zeit, die für die Suche nach einem bestimmten Code benötigt wird.

Die Softwareentwicklung selbst für die Softwareentwicklung ist für niemanden von Interesse, außer für Bildungszwecke, die nicht berücksichtigt werden dürfen. Softwareentwicklung hat immer ein Geschäftsziel. Hier ist anzumerken, dass es bei einem Geschäftsziel nicht immer um Geld geht. Vielleicht ist das Ziel, einen guten Ruf aufzubauen, jemandem zu helfen oder einfach nur Familie / Freunden zu zeigen („Schau, ich habe ein Spiel geschrieben!“) Und so weiter. Zum größten Teil ist es ein Geschäftsziel, das für die Wahl der Anwendungsarchitektur von grundlegender Bedeutung ist. Zunächst werden die Anforderungen analysiert, anhand derer geschlossen werden kann, ob die Software unterstützt wird und wie der Entwicklungszyklus aussehen wird. All diese Faktoren werden mit Informationen über Ressourcen überlagert - ein Team oder ihr eigenes Wissen. All diese Faktoren sind explizit oder implizit (wenn Sie gerade erst Ihre Reise in die Softwareentwicklung beginnen,Sie müssen nicht über Architektur nachdenken, aber Sie werden definitiv bald damit beginnen, zu beeinflussen, welche Ansätze und Muster Sie während der Entwicklung verwenden werden. Basierend auf der gewählten Architektur, den Ansätzen und Mustern wird eine Software-Codebasis angezeigt.

Bevor sich das Gespräch Designmustern zuwandte, konnte die Schönheit des Codes abstrakt betrachtet werden. Das heißt, es war möglich, sich hypothetisch eine Quelldatei vorzustellen, die aus dem Kontext genommen wurde. Ausgehend von der visuellen Komponente des Codes, ohne auf seine Semantik zu achten, können wir schließen, ob der Code schön ist oder nicht. Wenn in einem schönen Moment die abstrakte Quelle Teil der Codebasis wird (Teil von etwas Größerem, Teil von Software), werden neue Variablen in die Schönheitsgleichung des Codes eingeführt.

Angenommen, ein Projekt kommt zu einem neuen Entwickler, der den Code für dieses Projekt noch nie gesehen hat. Zunächst muss er in das Projekt eintreten, dh die Codebasis studieren. Während der Studie wird sich der Entwickler eine Meinung über das Projekt bilden, genauer gesagt darüber, woraus es besteht. Und in diesem Moment hat der Entwickler möglicherweise die folgenden Gedanken: „Diese Lösung ist hässlich“ oder umgekehrt: „Wow! Was für eine elegante (schöne) Lösung ... ". Schönheit bezieht sich in diesem Fall auf Architektur, die mittels Code ausgedrückt wird. Das heißt, das Konzept der semantischen Schönheit kann auch das Konzept der Code-Schönheit beeinträchtigen - sofern die Lösung architektonisch korrekt ist. Ist der Ansatz oder das Muster richtig ausgewählt und wird er beibehalten?

Dies ist genau der Ort, an dem alles am kompliziertesten wird:

• Wenn Sie mit diesem oder jenem Ansatz nicht vertraut sind, ist seine Idee möglicherweise nicht offensichtlich, unverständlich und wird in einem negativen oder positiven Kontext wahrgenommen. Ein solcher Fall ist der unvorhersehbarste.
• Sie sind möglicherweise mit dem Ansatz vertraut und nehmen ihn negativ, z. B. Anti-Patterns.
• Möglicherweise kennen Sie den Ansatz und nehmen ihn positiv auf.

In den letzten beiden Fällen fällt es Ihnen viel leichter, eine Schlussfolgerung zu ziehen und Ihre Gedanken über den Code und seine Schönheit auszudrücken.

Es stellt sich heraus, dass wir alle genau dafür gezwungen sind, Designmuster zu lernen - damit wir alle auf standardisierte Weise dieselbe Sprache sprechen. Darüber hinaus arbeitet unser Gehirn gerne mit einem Muster.

Wir sind jedoch an einem Punkt angelangt, an dem möglicherweise nicht alles so einfach ist, wie es scheint. Eine Quelldatei kann die Implementierung mehrerer Muster kombinieren. Wir lassen die Frage nach der Richtigkeit einer solchen Lösung aus, sie hängt sehr stark von der Situation ab und kann sowohl die richtige als auch die falsche Entscheidung sein. Das Verwässern der Implementierung einer Vorlage mit der Implementierung einer anderen kann die Wahrnehmung des Codes erschweren und ihn in unseren Augen hässlich machen. Ein falsch implementiertes Muster verschärft die Situation. Es mag Ihnen bis zum Ende so erscheinen, als ob Sie den Code verstehen, da er dem Muster untergeordnet ist, und dann stellt sich heraus, dass Sie ihn die ganze Zeit falsch wahrgenommen haben. In diesem Moment verliert ein schöner Code seinen ganzen Charme und wird nicht so schön, sondern mit einem Schatz. In diesem Fall könnte das Fehlen eines Musters hübscher aussehen.als ein falsch implementiertes Muster. Ein weiterer Aspekt betrifft falsche Ansätze oder Anti-Muster. Im Wesentlichen ist ein Anti-Muster ein Muster, das nicht verwendet werden sollte. Dies ist jedoch ein Muster, das dem Code in gewisser Weise Lesbarkeit und Verständlichkeit verleiht, dh Einfachheit und Schönheit. Es stellt sich heraus, dass die Verwendung von Mustern im Projektcode ein zweischneidiges Schwert ist.

API-Schreibstil

Apropos schönes Design der API: Meistens handelt es sich um einen bestimmten Dienst oder eine Bibliothek (oder ein Framework). Der Dienst scheint meistens etwas außerhalb des Codes zu sein, daher ist es in unserem Kontext besser, die Bibliothek zu betrachten. Die Auswahl des einen oder anderen API-Typs wirkt sich nicht nur auf die Struktur des Bibliothekscodes aus, sondern auch auf das Erscheinungsbild des Clientcodes, der die Bibliothek verwendet. Nebenbei kann ich 2 Styles mitbringen.

Der klassische Stil besteht darin, dass wir die Bibliothek in eine bestimmte Entität (Klasse) einrahmen und alle Methoden in dieser Klasse eine bestimmte Aktion ausführen und ein bestimmtes Ergebnis zurückgeben, das nicht vom Status der Hauptbibliotheksentität abhängt. Die meisten der verschiedenen Plugins sind im klassischen Stil erstellt, daher sollte es kein Problem geben, diesen Stil zu verstehen.

Der zweite Stil sind flüssige Schnittstellen . Dieser Ansatz besteht darin, dass wir am Ausgang der Bibliothek dasselbe Objekt erhalten, das die Aktion ausgelöst hat, das erst jetzt etwas anders konfiguriert ist. Ein Beispiel ist die Implementierung von LINQ in C #. Darin werden Kettenaktionen für dieselbe Sammlung ausgeführt (IEnumerable). Bei jedem Schritt der Anfrage ändern wir die Sammlung irgendwie, bis wir das gewünschte Ergebnis erhalten. Ein weiteres Beispiel aus C # ist ein Abhängigkeitsinjektionscontainer namens Zenject .

Darin werden Abhängigkeitsbinder in einem fließenden Stil geschrieben:

Container.Bind<Foo>().AsSingle().NonLazy().FromInstance(FooInstance"); 

Ein sehr bekanntes Beispiel für eine flüssige Schnittstelle von Swift ist das beliebte Alamofire- Framework.
Darin sieht man oft solche Designs:

 Alamofire.request( .GET, "http:foo.com", parameters: ["include_docs": "true"],encoding: .URL).validate().responseJSON { (response) -> Void in... } 

In den meisten Fällen kann der geeignete Stil basierend auf der aktuellen Situation ausgewählt werden. Aber niemand macht sich die Mühe, die Bibliotheks-API von einem Stil in einen anderen umzuschreiben, ohne die Funktionalität zu ändern, und dann wird es eine Frage des Geschmacks oder der Schönheit. Im Allgemeinen sind flüssige Schnittstellen nicht so häufig wie der klassische Stil, aber abhängig von einer Vielzahl von Faktoren können sie den Code schöner oder hässlicher machen. Das Ableiten einer universellen Formel schlägt hier ebenfalls fehl.

Sprachschönheitsprodukte

Wir sind bereits zu dem Schluss gekommen, dass wir für Schönheit Vorlagen brauchen, ohne sie irgendwo. Muster sollten erkennbar, einfach und kurz sein. Bei Designmustern stellte sich heraus, dass alles mehrdeutig war. Neben architektonischen Mustern helfen aber auch Konstruktionen der Sprache, die Sie schreiben. Das gleiche Entwurfsmuster, das in einer Sprache implementiert ist, kann abhängig von bestimmten Sprachwerkzeugen schön und hässlich aussehen.

Gemeinsam für die meisten, wenn nicht alle Programmiersprachen, dann kommentiert für die meisten ein Sprachwerkzeug, das die Semantik des Codes nicht beeinflusst, aber seine Schönheit beeinflusst. Das Hinzufügen eines guten Kommentars an der richtigen Stelle kann das Erscheinungsbild des Codes verbessern. Es lohnt sich jedoch, einen Kommentar isoliert vom allgemeinen Stil zu schreiben (z. B. können Sie in c-ähnlichen Sprachen Kommentare auf drei verschiedene Arten beschreiben), da dies das Gesamtbild sofort beeinträchtigt und die Wahrnehmung des Codes selbst visuell ablenkt.

Schauen wir uns als Opfer einige der Tools an, die C # uns zur Verfügung stellt. Eines der einfachsten Werkzeuge in dieser Sprache ist das Schlüsselwort var . Es wird vermieden, den Typ einer Variablen explizit anzugeben, wenn sie deklariert wird, wobei var für einen beliebigen Typ oder eine beliebige Schnittstelle verwendet wird.
Einerseits hilft dieses Tool, fast alle Typnamen in Methodenkörpern zu entfernen. Auf der anderen Seite denken Sie darüber nach, zu welchem ​​Typ diese oder jene Variable gehört. Die überwiegende Mehrheit der Entwickler, die C # kondolieren, hält die Verwendung von var für eine gute Praxis. Das heißt, dieses Sprachwerkzeug kann in Bezug auf die Schönheit des Codes als nützlicher als schädlich angesehen werden.

Mit der Direktive #region #endregion können Sie Codeblöcke angeben, die in der IDE reduziert werden können. Es ist eines der umstrittensten Werkzeuge. In einigen Teams ist die Verwendung dieser Richtlinie strengstens untersagt, in anderen wird sie obligatorisch empfohlen. Ein Argument dafür, diese Anweisung nicht zu verwenden, besteht darin, dass sie den Code mit semantisch nutzlosen Einfügungen verdünnt, die Sie daran hindern, sich auf den Code selbst zu konzentrieren. Als Argument „für“ kann man eine Praxis anführen, bei der Klassenmethoden nach Regionen so gruppiert sind, dass Sie einfach und ohne Bearbeitung des Codes dessen interne Implementierung oder eine externe API oder eine Implementierung des einen oder anderen Musters sehen können (das häufig nach Vorlage und aussieht es wird in die Region entfernt, damit die Augen keinen Kallus bekommen). Zusammenfassend können wir sagen, dass das Tool mehr als umstritten ist.

Das letzte Werkzeug, das Sie unbedingt berücksichtigen sollten, sind Lambda-Ausdrücke und anonyme Methoden. Generell können wir sagen, dass beide Tools so konzipiert sind, dass sie die Methode so kompakt wie möglich beschreiben, oft ohne sie explizit zu deklarieren. Zu diesem Zweck können wir mit Funktionen wie dem Verringern der Signatur, den Arten von Eingabe- und Ausgabeparametern Abhilfe schaffen und den Compiler dazu zwingen, all dies explizit für uns anzuzeigen. Das Tool, das viele als integralen Bestandteil der Sprache betrachten, hat jedoch die umstrittenste Position in Bezug auf die Schönheit des Codes. Zum Beispiel ist LINQ ohne Lambda-Ausdrücke kaum vorstellbar, sie sind kompakt und prägnant. Wenn Sie jedoch ihre Verwendung missbrauchen, kann der gesamte Code in der Klasse leicht in ein unlesbares Chaos umgewandelt werden.

Sprachwerkzeuge wie Erweiterungsmethoden (Erweiterungsmethoden), foreach vs for, anonyme Methoden, ternärer Operator, Verkettung von Konstruktoren und andere bleiben außerhalb des Analysebereichs. Alle von ihnen sind auch durch die kontroverse Verwendung in bestimmten Teilen des Codes vereint. Daraus können wir schließen, dass es keinen perfekten syntaktischen Zucker gibt, was den Code zweifellos schöner macht.

Als zusätzliches Material zum Thema syntaktischer Zucker kann ich die junge Programmiersprache Swift nicht verfehlen. Zum größten Teil bietet es keine eindeutigen Sprachkonstrukte. Seine Fähigkeit, das ";" Am Ende der Codezeile wurde ich am meisten von meiner aktuellen Vorstellung vom Prozess des Schreibens von Code auseinandergerissen. Ich weiß, dass dieses Merkmal beim üblichen Lesen nicht als ungewöhnlich empfunden wird. Aber während der Kampfentwicklung in dieser Sprache war es zunächst ziemlich schwierig, wieder aufzubauen. Schreiben Sie nicht ";" Am Ende einer Codezeile steht die empfohlene Vorgehensweise in dieser Sprache. Es scheint, dass dies eine echte Kleinigkeit ist, aber Sie können auch außerhalb des Programmierkontexts eine Parallele dazu ziehen. Diese Parallele liegt in den Interpunktionsregeln der meisten Sprachen der Welt. Wir sind es gewohnt, jahrelang Punkte am Ende eines Satzes zu setzen, um ein Muster für das Erkennen vollständiger Gedanken in einem Text zu bilden. Vielleicht in einer einfachen Gelegenheit, ";" Im Code ist eine versteckte Regel versteckt, die wie folgt ausgedrückt werden kann: Schreiben Sie nur eine Code-Frist in eine Zeile der Quellcodedatei. Und diese Empfehlung wird letztendlich in Form der Praxis ausgedrückt, nicht ";" am Ende der Zeile, ohne die Möglichkeit zu geben, dieser Zeile etwas anderes hinzuzufügen. Swift hat jedoch auch einige gute Syntaxinnovationen, wie beispielsweise die Guard- Anweisung.

Wenn es um ";" geht Am Ende einer Codezeile ist es schwer, die Python-Sprache nicht zu erwähnen. Diese Sprache ist voll mit allen Arten von syntaktischem Zucker. Ein beträchtlicher Teil dieses Zuckers ist umstritten, auch wenn ich das so sagen darf, eindeutig nicht notwendig, was das Lesen des Codes nur erschwert. All dies ist jedoch im Zusammenhang mit der Tatsache, dass der Schwellenwert für die Eingabe der Sprache extrem niedrig ist, nicht eindeutig. Es scheint, dass die Sprachentwickler alle Anstrengungen unternommen haben, um sicherzustellen, dass Sie Code in Python schreiben können, wobei die Syntax so wenig wie möglich berücksichtigt wird. Ein weiteres Merkmal dieser Sprache ist das Fehlen einer expliziten Zuordnung von Codeblöcken (die Klammern "{}" werden nicht verwendet). Anstatt Python-Leben explizit hervorzuheben, eingerückt. Einerseits wird dies visuell besser wahrgenommen, da der Text weniger bedeutungslose Dienstzeichen enthält. Auf der anderen Seite müssen Sie auf die Einrückung achten, die in den meisten Sprachen eindeutig nicht erforderlich ist. Diese Sprache könnte nicht ohne Unterbrechungen von C-Mustern auskommen. Anstelle einer Try-Catch-Anweisung haben wir Try-Except. Der Name sieht logisch aus, aber es ist schwierig, ihn neu zu erstellen.

Als letztes kontroverses Beispiel für ein Sprachwerkzeug, das in vielen Sprachen zu finden ist, werde ich verallgemeinerte Klassen und Methoden (Generics) geben. Verallgemeinerungen an sich sollen uns ersparen, dass wir Code mit starkem Boilerplate stark duplizieren müssen. Das heißt, zumindest im Hinblick auf die Beseitigung von Codeduplikationen an verschiedenen Stellen dienen Verallgemeinerungen als Werkzeug, um den Code schöner zu machen. Das Konzept eines von einem anderen Typ parametrisierten Typs wird jedoch als ziemlich schwierig empfunden. Jedes Mal, wenn man auf die Verallgemeinerung im Code stößt, muss man mehr Zeit für das Verständnis der Semantik aufwenden als für das Verständnis der Semantik von nicht verallgemeinertem Code.

Angesichts der oben genannten Punkte kann argumentiert werden, dass syntaktischer Zucker auch ein kontroverses Werkzeug ist, das den Code mehr und weniger schön machen kann.

Die Software-Seite, die uns helfen kann

Die gesamte Subjektivität des Ansatzes zum Schreiben von Code und das Konzept seiner Schönheit können verwirrend sein. Dieses Problem ist besonders akut, wenn ein neuer Entwickler zu einem gut koordinierten Team kommt. Oft hat ein Anfänger keine andere Wahl, als den bereits geschriebenen Code nachzuahmen und sich im Kurs an den vorhandenen Stil anzupassen. Dies ist, was die meisten Menschen nicht mögen, wenn sie zu einem neuen Job kommen. Alle Ihre Wahrnehmungsmuster, neuronalen Ketten und Reflexe, die sich im Laufe der Jahre der Erfahrung gebildet haben, beginnen Schaden zuzufügen, anstatt frühere Vorteile. Glücklicherweise ist es zumindest in diesem Bereich möglich, einige allgemeine Praktiken einzuführen, die frei von Subjektivität sind.

Darüber hinaus haben wir lange darüber nachgedacht und uns darum gekümmert. Moderne IDEs haben sich von herkömmlichen Texteditoren weit entfernt und können die Beibehaltung des Codestils erheblich erleichtern. Die Syntaxhervorhebung ist vielleicht das älteste Werkzeug aus der IDE. Trotz seiner Einfachheit und Vertrautheit ist die Idee darin dieselbe - eine spezifische Vorlage zu bilden, die beim Schreiben von Code hilft. Das einfachste Beispiel ist das Unterstreichen eines bestimmten Wortes im Code in Rot bei einem Fehler. Darüber hinaus sind viele zweifelhafte Stellen, auf die Sie achten sollten, gelb markiert. All dies zusammen ist eine Vorlage, die seit unserer Kindheit mit Hilfe von Ampeln in unserem Kopf geformt wurde.

In Bezug auf die Schönheit des Codes versuchen moderne IDEs auch zu helfen, so gut sie können. Sie können beispielsweise eine relativ junge IDE von JetBrains - Rider übernehmen. Hier helfen die Vereinfachung der logischen Bedingungen und die Hilfe bei der Auswahl eines Variablennamens, die Rechtschreibprüfung bei Kommentaren und Variablennamen, die automatische Ausrichtung und vieles mehr.

Das Benennen von Variablen, das Ausrichten des Codes, das Einfügen von Tabulatoren anstelle von Leerzeichen und Leerzeichen in den zusammengeführten Code - all dies ist der Hauptpunkt, der dazu beiträgt, den Text als Code in einem für Sie geeigneten Stil zu gestalten. Und die IDE nimmt die meisten dieser Änderungen im Hintergrund für Sie vor. Es stellt sich heraus, dass Sie ihr nur beibringen müssen, was Sie wollen, und anschließend wird es zu einem unverzichtbaren Assistenten für Sie, was Ihnen viel Zeit spart. Die Details zum Unterrichten Ihrer IDE über Ihren Stil sind für das Thema dieses Artikels nicht relevant. Wenn Sie jedoch über dieses Konzept als Ganzes nachdenken, ist der Prozess dem Prozess der Einführung eines neuen Entwicklers in das Team sehr ähnlich. Ein unverzichtbares Werkzeug dafür ist ein Code-Style-Agreement-Dokument. Der einzige Unterschied besteht darin, dass der Entwickler es in Form eines Dokuments erhält und die IDE es in einer internen Konfigurationsdatei in einem Format generiert oder speichert, das nur einer versteht.

Der unbestreitbare Schritt in Richtung eines schönen Codes ist daher seine Standardisierung. Viele Unternehmen auf der ganzen Welt vernachlässigen es, ein Dokument zu schreiben, das den Codestil standardisiert. Es kommt vor, dass eine Katastrophe erschreckende Ausmaße annimmt - die Anzahl der Projekte, die gleichzeitig im Unternehmen entwickelt werden, entspricht der Anzahl der im Unternehmen verwendeten Codierungsstile. Unter solchen Umständen wird der Übergang eines Entwicklers von einem Projekt zu einem anderen noch trivialer. Wenn niemand die Standardisierung der Codebasis überwacht, verwandelt sich der Code in der Regel in einen Massencode, und die Anpassung an ein neues Projekt fühlt sich an, als würde man zu einem anderen Unternehmen wechseln, was mehr Stress verursacht als es könnte. Mit der Zunahme des Stressniveaus beim Übergang zu einem neuen Projekt erhöht sich auch die Anpassungszeit.

Solche Probleme können vermieden werden, indem nur ein Dokument mit einer Codestilkonvention auf Lager ist. Dieses Dokument kann auch als Entwicklungswerkzeug betrachtet werden. Mit einem solchen Dokument und einer modernen IDE in Ihrem Arsenal können Sie Ihr Leben erheblich vereinfachen, indem Sie den Codestil auf IDE-Ebene automatisieren. Dies verringert den Schwellenwert für den Entwickler, dem Team beizutreten, und verringert die Anzahl der Ansprüche gegen den Entwickler während der Codeüberprüfung. Die Idee, Entwicklungswerkzeuge maximal zu automatisieren und zu nutzen, ist alles andere als neu. Sie findet sich in vielen Quellen, einschließlich des legendären Buches "Programmer-Pragmatist".

Zusammenfassend: Entwicklungswerkzeuge wirken sich sehr positiv auf die Schönheit des Codes aus. Darüber hinaus beeinflusst der Faktor der Subjektivität die Nützlichkeit dieser Werkzeuge nicht.

Eine Software-Seite, die alles ruinieren kann.

Wir haben uns bereits mit dem guten Software-Teil vertraut gemacht. Aber zielen alle technischen Lösungen darauf ab, den Code schöner zu machen? Wenn ein Produkt fast zur Veröffentlichung bereit ist, stellt sich heraus, dass es nicht den technischen Eigenschaften eines bestimmten Geräts entspricht, was für uns so wichtig ist. Dieses Problem ist im Bereich der Entwicklung von Spielesoftware besonders akut. Jemand kann vernünftigerweise Einwände haben, dass Sie sofort optimale Software schreiben und während der Entwicklung optimieren können, um die optimalste Lösung zu erzielen. Zu solchen Einwänden kann man ein Gegenargument anführen:

Vorzeitige Optimierung ist die Wurzel allen Übels. -Donald Knut

Die Debatte darüber, ob diese Aussage wahr ist oder nicht, betrifft nicht die Schönheit des Kodex und geht über den Rahmen der gegenwärtigen Argumentation hinaus.

Die Optimierung kann sich jedoch nachteilig auf die Schönheit des Codes auswirken. Dies ist nicht immer der Fall, aber es gibt einige Praktiken, die höchstwahrscheinlich weit entfernt von dem am besten lesbaren Code ausgedrückt werden können. Beispiele für solche Optimierungen:

• Ausrichtung von Daten / Variablen im Speicher
• Verwenden von datenorientiertem Design (DOD)
• Implementierung von asynchronen oder Multithread-Aktionen

Diese Optimierungen sind recht schwierig zu implementieren, aber für die Entwicklung von Hochleistungsrechnern und in einer Reihe anderer Situationen erforderlich. Beispielsweise kann eine übermäßige Verwendung von Multithread-Interaktionen den Code erheblich verkomplizieren. Wir bekommen eine Situation, in der die Schönheit des Codes für die technische Optimierung geopfert werden kann.

An wen kann ich mich wenden?

Wir haben entschieden, dass es unabhängig von der Subjektivität des Konzepts der Schönheit des Codes Praktiken gibt, die bei der Pflege helfen - ein Dokument über den Codestil und eine ordnungsgemäß konfigurierte IDE. Dieses Paket kann das Leben wirklich erleichtern, aber es kann kein 100% iges Ergebnis garantieren. Der Grund dafür ist der menschliche Faktor. Der Entwickler ist möglicherweise mit dem Dokument im Codestil vertraut, verfügt über eine ordnungsgemäß konfigurierte IDE und ignoriert dennoch alle Regeln und Warnungen der IDE. Dafür kann es mindestens zwei Gründe geben:

• Skrupelloser Entwickler. Vielleicht ist der Entwickler noch nicht an einen neuen Stil für ihn gewöhnt und schreibt auf seine übliche Weise. Oder vielleicht hält er es einfach nicht für wichtig, einen gemeinsamen Stil beizubehalten, auf den es sich zu achten lohnt.
• Eine bestimmte Kombination von Umständen. Die meisten von uns kennen oder haben Agile ausprobiert und üben Sprints mit einer festen Frist und einer Reihe von Aufgaben. Im Leben gibt es Situationen, in denen eine Anfrage „von oben“ über die Notwendigkeit kam, genau hier und gestern eine wichtige Funktion zu implementieren, die im aktuellen Sprint nicht enthalten war. Kein Unternehmen kann garantieren, dass dies nicht geschieht. Bei der Implementierung solcher Funktionen passieren sehr häufig Dinge wie eine „Entscheidung über das Knie“ und ein „Hotfix“. Oft werden solche Dinge aus Gründen der Geschwindigkeit gemacht und es bleibt einfach keine Zeit, der Schönheit einer solchen Bearbeitung zu folgen.

Es spielt keine Rolle, aus welchem ​​Grund der Entwickler aufgefordert wurde, einen hässlichen Code zu schreiben und ihn in eine gemeinsame Codebasis zu füllen. Gleichzeitig ist es wahrscheinlich, dass eine solche Änderung in einer so hässlichen Form verbleibt, sobald sie in die Pressemitteilung aufgenommen wird. Es scheint, dass was schief gehen könnte, wenn wir alle verstehen, dass dies nur in Ausnahmesituationen geschieht und dass dies nicht möglich ist? Das Wesentliche des Problems ist, dass dies der Präzedenzfall ist, der stattgefunden hat. Dies bedeutet, dass es sehr wahrscheinlich ist, dass nach einiger Zeit, wenn jeder den Kontext der aufgetretenen Situation vergisst, ein Entwickler während der Arbeit auf diesen hässlichen Code stößt. Dann könnten sich falsche Gedanken in seinen Kopf eingeschlichen haben, dass, wenn dies bereits im Projekt ist, das Hinzufügen einer weiteren Portion nicht schlimmer wird. Das Rezept für eine Katastrophe ist einfach: Wiederholen Sie die letzte Aktion n Mal, bis das gesamte Projekt aus solchen "außergewöhnlichen" Orten besteht - zerbrochenen Fenstern.

Ein solcher Effekt ist in der Broken Window Theory sehr gut beschrieben. Sie können ganz einfach mit zerbrochenen Fenstern umgehen - wir brauchen nur einen Wachmann, der den Code überwacht. In Bezug auf die Programmierung passt eine solche Lösung gut zum Konzept der Codeüberprüfung. Ich kann keinen einzigen schlechten Nebeneffekt der Praxis der Durchführung regelmäßiger Codeüberprüfungen nennen. Das einzige, was führende Leute anfassen können, ist die Verschwendung einer erheblichen Menge an Zeit für die Durchführung einer Codeüberprüfung und die Korrektur von Kommentaren dazu. Für solche Menschen kann es schwierig sein zu erklären, was technische Schulden sind und woher sie kommen. Im Kontext der Schönheit des Codes ist die Codeüberprüfung jedoch eine rein positive Praxis.

Neben der Person, die die Codeüberprüfung für das Projekt durchführt (oder mehreren Personen), können Sie sich auch an die Entwickler der Sprache oder an den Programmierguru wenden, um Rat zu erhalten. Natürlich sollten Sie sich nicht darauf verlassen, dass Sie einen Brief schreiben oder direkt von diesem Guru anrufen können. Für die meisten Programmiersprachen gibt es jedoch offizielle oder allgemein akzeptierte
Code-Stil-Standards, die von seriösen Personen geschrieben wurden. Beispiele:

1. Python - PEP8
2. C # - StyleCop
3. Swift - Der offizielle raywenderlich.com Swift Style Guide
4. Objective-C - Der offizielle Zielführer für raywenderlich.com Objective-C

Das Befolgen allgemein anerkannter Codestilstandards ist eine bewährte Methode, um Ihren Code schön zu halten. Obwohl Subjektivität auch in allgemein anerkannten Standards vorhanden ist, kann nicht geschlossen werden, dass Code, der nach gemeinsamen Standards geschrieben wurde, schön sein wird.

Schlussfolgerung ohne Schlussfolgerung

Alle überlegten Gedanken zur Schönheit des Codes führen ausschließlich zu seiner Subjektivität, auch in Bezug auf seine Einfachheit. Die Einfachheit ergibt sich wiederum daraus, wie einfach es ist, den Code zu verstehen und wie kompakt er ist (oder umgekehrt). Alle beschriebenen Tools, die Wahl zwischen dem einen oder anderen Ansatz, bilden eine Handschrift, die von anderen Entwicklern anerkannt und unterstützt wird. Gleichzeitig stellt sich heraus, dass sich das Konzept der Schönheit im Code immer noch für eine gewisse, wenn auch sehr schwache Standardisierung eignet. Im Allgemeinen können wir davon ausgehen, dass die Strukturierung stärker mit der Schönheit des Codes korreliert, obwohl hier Variationen möglich sind.
Es kann niemals gelingen, unter allen Entwicklern der Welt einen Konsens zu erzielen. Es lohnt sich jedoch, sich dem Abschluss des Konzepts der Code-Schönheit zu nähern. Wenn Sie darüber nachdenken, warum Sie es vorziehen, auf die eine oder andere Weise zu schreiben, beginnen Sie vielleicht, besser lesbaren Code zu schreiben und Ihre Gedanken klarer im Code auszudrücken. Oder ein solches Verständnis hilft Ihnen, die Wahl in Richtung eines bestimmten der vorhandenen Stile zu treffen.