Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "Lange Namen sind lang" von Bob Nystrom.
Eines der intelligenten Dinge, die Google tut, ist die strikte Codeüberprüfung. Jede Änderung, bevor Sie zum Hauptzweig gelangen dürfen, wird in mindestens zwei Richtungen berücksichtigt. Zuerst führt jemand im Team eine Routineprüfung durch, um sicherzustellen, dass der Code das tut, was er sollte.
Der zweite Schritt erfolgt jedoch, wenn die Lesbarkeit des Codes überprüft wird. Dies stellt sicher, dass andere Entwickler diesen Code in Zukunft unterstützen können. Ist dieser Code leicht zu verstehen und zu pflegen? Entspricht dieser Code dem Stil und den Redewendungen der Sprache? Ist der Code gut dokumentiert?
Die Verwendung der Dart- Sprache bei Google gewinnt allmählich an Dynamik, und ich habe mich viel mit einer solchen Codeüberprüfung befasst. Für einen Sprachentwickler ist dies ein sehr aufregender Prozess. Ich bekomme aus erster Hand einen Überblick darüber, wie Leute Dart verwenden, was für seine Entwicklung wirklich nützlich ist. Ich habe eine klarere Vorstellung davon, welche Fehler häufig sind und welche Funktionen häufig verwendet werden. Ich fühle mich wie ein Ethnograph, ein Tagebuch über das Leben der Eingeborenen.
Dies ist jedoch auf keinen Fall der Fall. Verdammt, es sind nicht einmal Darts. Worüber ich sprechen möchte, ist das, was ich in vielen Codes sehe und was mich verrückt macht: zu lange Namen .
Ja, die Namen sind möglicherweise zu kurz. In jenen Tagen, als C verlangte, dass nur externe Bezeichner bis zu den ersten sechs Zeichen eindeutig sind; wenn die Autovervollständigung noch nicht erfunden wurde; Wenn jeder Tastendruck wie ein Aufstieg durch den Schnee war, war dies ein Problem. Ich bin froh, dass wir jetzt in einer futuristischen Utopie leben, in der Tastatur-Fürze wie p , idxcrpm und x3 selten sind.
Aber das Pendel schwang zu weit in die andere Richtung. Wir müssen nicht Hemingway sein, wir müssen auch nicht Tennessee Williams sein. Zu lange Namen beeinträchtigen auch die Klarheit des Codes, in dem sie verwendet werden. Sehr lange Variablennamen überschatten die Operationen, die Sie an ihnen ausführen. Das visuelle Scannen von Code wird schwierig. Um die Anforderungen an die Codebreite zu erfüllen, werden zusätzliche Zeilenumbrüche angezeigt, die den logischen Codefluss unterbrechen. Lange Methodennamen verbergen ihre ebenso wichtigen Argumentlisten. Lange Variablen sind bei der Wiederverwendung ärgerlich, was dazu führt, dass sich Ketten von Methoden oder Kaskaden dehnen.
Ich habe Variablennamen gesehen, die länger als 60 Zeichen sind. Sie können dort ein Haiku oder Koan platzieren (und den Leser wahrscheinlich mehr als den von Ihnen gewählten Namen aufklären). Aber keine Angst, ich bin hier um zu helfen.
Einen guten Namen wählen
Jeder Name in der Programmierung hat zwei Ziele:
- Der Name sollte klar sein : Sie müssen wissen, worauf er sich bezieht.
- Der Name muss korrekt sein : Sie müssen wissen, wofür er nicht gilt.
Sobald der Name diese Ziele erreicht hat, sind alle zusätzlichen Zeichen totes Gewicht. Hier sind einige Richtlinien, die ich verwende, wenn ich Dinge in meinem Code benenne:
1. Vermeiden Sie Wörter, die explizit in einem Variablen- oder Parametertyp angegeben sind
Wenn Ihre Sprache über ein statisches Typsystem verfügt, kennen Benutzer normalerweise den Typ der Variablen. In der Regel sind die Methoden recht kurz, sodass selbst bei der Betrachtung einer lokalen Variablen, bei der der Typ nicht sofort angenommen werden kann, oder bei einer Codeüberprüfung oder an einem Ort, an dem die statische Codeanalyse nicht möglich ist, selten etwas mehr als ein paar Zeilen erforderlich sind oben, um den Variablentyp zu bestimmen.
Vor diesem Hintergrund ist es nicht erforderlich, den Typ im Variablennamen anzugeben. Wir haben gerade die ungarische Notation aufgegeben. Lass los und vergiss :
Insbesondere für Sammlungen ist es fast immer besser, ein Substantiv im Plural zu verwenden, das den Inhalt beschreibt, als ein Substantiv im Singular, das eine Sammlung beschreibt . Wenn sich der Leser mehr um das kümmert, was sich in der Sammlung befindet, sollte der Titel dies widerspiegeln.
Dies gilt auch für Methodennamen. Der Name der Methode muss weder ihre Parameter noch deren Typen beschreiben - die Liste der Parameter erledigt dies für Sie.
Dies führt dazu, dass Anrufe besser gelesen werden:
mergeTableCells(tableCells); sortEventsUsingComparator(events, comparator);
Ist es nur ich oder gibt es hier ein Echo-Echo?
2. Vermeiden Sie Wörter, die den Namen nicht eindeutig definieren
Manche Leute neigen dazu, alles, was sie über etwas wissen, in den Namen einer Variablen zu schreiben. Denken Sie daran, dass der Name eine Kennung ist : Er gibt den Ort an, an dem er definiert ist. Dies ist kein vollständiger Katalog von allem, was der Leser über das Objekt wissen möchte. Definition wird es besser machen. Der Name wird ihn nur dorthin führen.
Wenn ich den Namen als recentlyUpdatedAnnualSalesBid aktualisiertes Jahresbuch sehe, frage ich mich:
- Gibt es aktualisierte jährliche Kundenaufträge, die nicht auf dem neuesten Stand sind?
- Gibt es aktuelle jährliche Verkaufsanfragen, die nicht aktualisiert wurden?
- Gibt es kürzlich aktualisierte jährliche Nichtverkaufsanwendungen?
- Gibt es kürzlich aktualisierte jährliche Verkaufsdaten, bei denen es sich nicht um Gebote handelt?
Wenn die Antwort auf mindestens eine dieser Fragen "Nein" lautet, weist dies normalerweise auf ein zusätzliches Wort im Namen hin.
Natürlich können Sie auch zu weit gehen. Die Verkürzung des ersten zu bietenden Beispiels ist möglicherweise zu vage. Aber wenn Sie Zweifel haben, lassen Sie es so. Sie können später jederzeit eine zusätzliche Klassifizierung hinzufügen, wenn der Name die Ursache des Konflikts ist oder ungenau ist. Es ist jedoch unwahrscheinlich, dass Sie später zurückkehren, um all dieses überschüssige Fett zu reduzieren.
3. Vermeiden Sie Wörter, die aus dem Kontext klar hervorgehen.
Ich kann das Wort "I" in diesem Absatz verwenden, weil Sie wissen, dass dieser Text von Bob Nystrom stammt. Ich muss "Bob Nystrom" hier nicht ständig wiederholen (trotz der Versuchung von Bob Nystrom, Bob Nystrom auf diese Weise zu stärken). Der Code funktioniert genauso. Eine Methode oder ein Feld tritt im Kontext einer Klasse auf. Eine Variable tritt im Kontext einer Methode auf. Nehmen Sie diesen Kontext als selbstverständlich und wiederholen Sie ihn nicht.
In der Praxis bedeutet dies, dass je tiefer der Name eingebettet ist, desto mehr umgebender Kontext er hat. Infolgedessen stellt sich heraus, dass dieser Name kürzer sein wird. Als Ergebnis sehen Sie ein Muster: Bezeichner, die sich in einem engeren Bereich befinden, haben kürzere Namen.
4. Vermeiden Sie Wörter, die nichts bedeuten.
Ich sehe diesen Fehler oft in der Spielebranche. Einige Entwickler erliegen der Versuchung und blasen die Namen ihrer Variablen auf, indem sie Wörter aus „ernsthaften Geschäften“ hinzufügen. Sie glauben, dass dies ihren Code wichtiger macht und sie dementsprechend wichtiger macht.
In den meisten Fällen enthalten diese Wörter keine aussagekräftigen Informationen für den Entwickler. In der Regel fallen Verdächtigungen auf folgende Wörter: data , state , amount , value , manager , engine , object , entity und instance .
Ein guter Name malt ein Bild im Kopf des Lesers. Wenn wir irgendetwas als "Manager" bezeichnen, geben wir dem Leser keine Informationen darüber, was dieses Objekt tun soll. Führt es eine Leistungsbeurteilungsberechnung durch? Ernennt Beförderung zu ihren Mitarbeitern?
Fragen Sie sich: "Bedeutet dieser Name dasselbe, wenn ich dieses Wort wegnehme?" Wenn ja, dann spielt das Wort keine Rolle - fahren Sie von der Insel weg.
Anwenden des Handbuchs auf ... Waffeln
Um Ihnen eine Vorstellung davon zu geben, wie diese Regeln in der Praxis funktionieren, finden Sie hier ein Beispiel, das gegen alle Regeln verstößt. Dieses erfundene Beispiel ist dem echten Code sehr ähnlich, der mir bei der Codeüberprüfung häufig vorkommt.
class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffleWithStrawberryList( List<Strawberry> strawberryList) { ... } }
Dank der Art des Parameters wissen wir, dass die Methode eine Liste von Erdbeeren akzeptiert (# 1). Lassen Sie uns diese Informationen aus einem Namen herausschneiden:
class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffle( List<Strawberry> strawberries) { ... } }
Wenn das Programm keine geschmacklosen belgischen Waffeln oder Waffeln anderer Nationalitäten enthält, können wir alle Adjektive sicher verwerfen (Nr. 2):
class WaffleObject { void garnishWaffle(List<Strawberry> strawberries) { ... } }
Diese Methode befindet sich in WaffleObject , sodass wir aus dem Kontext wissen, was genau sie dekorieren wird (# 3):
class WaffleObject { void garnish(List<Strawberry> strawberries) { ... } }
Offensichtlich ist dies ein Objekt. Alles ist ein Objekt in der objektorientierten Programmierung (# 4):
class Waffle { void garnish(List<Strawberry> strawberries) { ... } }
Jetzt viel besser.
Ich denke, das sind ziemlich einfache Empfehlungen. Sie haben das Recht zu denken, dass es sinnlos ist, sich über solche Kleinigkeiten Sorgen zu machen. Ich glaube jedoch, dass das Benennen eine der grundlegendsten Aufgaben ist, die wir beim Programmieren ausführen. Namen sind die Struktur, die wir dem formlosen Meer von Bits auferlegen, dem Computer.