it-swarm.com.de

Gibt es eine Entschuldigung für kurze Variablennamen?

Dies ist zu einer großen Enttäuschung über die Codebasis geworden, in der ich gerade arbeite. Viele unserer Variablennamen sind kurz und unbeschreiblich. Ich bin der einzige Entwickler, der noch an dem Projekt beteiligt ist, und es gibt keine Dokumentation darüber, was die meisten von ihnen tun. Daher muss ich zusätzliche Zeit darauf verwenden, herauszufinden, was sie darstellen.

Zum Beispiel habe ich einen Code gelesen, der die Definition einer optischen Oberfläche aktualisiert. Die zu Beginn eingestellten Variablen waren wie folgt:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Vielleicht bin ich es nur, aber es hat mir im Wesentlichen nichts darüber gesagt, was sie darstellten, was das Verständnis des Codes weiter unten schwierig machte. Ich wusste nur, dass es sich um eine Variable handelte, die irgendwo eine bestimmte Zeile aus einer bestimmten Tabelle analysiert hatte. Nach einigem Suchen fand ich heraus, was sie bedeuteten:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Ich habe sie im Wesentlichen in das umbenannt, was ich dort oben habe. Es verlängert einige Zeilen, aber ich denke, das ist ein fairer Kompromiss. Diese Art von Namensschema wird jedoch im gesamten Code verwendet. Ich bin mir nicht sicher, ob es sich um ein Artefakt von Entwicklern handelt, die durch die Arbeit mit älteren Systemen gelernt haben, oder ob es einen tieferen Grund dafür gibt. Gibt es einen guten Grund, Variablen auf diese Weise zu benennen, oder bin ich berechtigt, sie auf aussagekräftigere Namen zu aktualisieren, wenn ich auf sie stoße?

140
KChaloux

Es scheint, dass diese Variablennamen auf den Abkürzungen basieren, die Sie in einem Physiklehrbuch erwarten würden, das verschiedene optische Probleme bearbeitet. Dies ist eine der Situationen, in denen kurze Variablennamen häufig längeren Variablennamen vorzuziehen sind. Wenn Sie Physiker haben (oder Leute, die es gewohnt sind, die Gleichungen von Hand zu erarbeiten), die es gewohnt sind, gebräuchliche Abkürzungen wie Rin, Rout usw. zu verwenden, ist der Code mit diesen Abkürzungen viel klarer als mit längeren Variablennamen. Es macht es auch viel einfacher, Formeln aus Papieren und Lehrbüchern mit Code zu vergleichen, um sicherzustellen, dass der Code die Berechnungen tatsächlich ordnungsgemäß ausführt.

Jeder, der mit Optik vertraut ist, erkennt sofort etwas wie Rin als inneren Radius (in einem Physikpapier würde das in als Index gerendert), Rout als äußeren Radius usw. Obwohl dies mit ziemlicher Sicherheit der Fall wäre in der Lage zu sein, etwas wie innerRadius mental in die bekanntere Nomenklatur zu übersetzen, würde dies den Code für diese Person weniger klar machen. Dies würde es schwieriger machen, Fälle zu erkennen, in denen eine vertraute Formel falsch codiert wurde, und es würde schwieriger machen, Gleichungen im Code in und aus den Gleichungen zu übersetzen, die sie in einem Papier oder einem Lehrbuch finden würden.

Wenn Sie die einzige Person sind, die sich diesen Code jemals ansieht, müssen Sie nie zwischen dem Code und einer Standardoptikgleichung übersetzen, und es ist unwahrscheinlich, dass ein Physiker den Code in Zukunft vielleicht noch einmal betrachten muss Eine Umgestaltung ist sinnvoll, da der Nutzen der Abkürzungen die Kosten nicht mehr überwiegt. Wenn dies jedoch eine Neuentwicklung wäre, wäre es mit ziemlicher Sicherheit sinnvoll, im Code dieselben Abkürzungen zu verwenden, die Sie in der Literatur finden würden.

234
Justin Cave

Variablen mit kurzer Lebensdauer sollten in Kürze benannt werden. Als Beispiel schreiben Sie nicht for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Stattdessen verwenden Sie for(int i ....

Als Faustregel könnte man sagen, dass der Name umso kürzer sein sollte, je kürzer der Variablenbereich ist. Schleifenzähler sind oft nur einzelne Buchstaben, z. B. i, j und k. Lokale Variablen sind so etwas wie base oder from und to. Globale Variablen sind dann etwas ausgefeilter, zum Beispiel EntityTablePointer.

Möglicherweise wird eine solche Regel bei der Codebasis, mit der Sie arbeiten, nicht befolgt. Es ist jedoch ein guter Grund für ein Refactoring!

89
zxcdw

Das Problem mit dem Code sind nicht die Kurznamen, sondern das Fehlen eines Kommentars, der die Abkürzungen erklärt oder auf einige hilfreiche Materialien zu den Formeln verweist, aus denen die Variablen abgeleitet werden.

Der Code setzt einfach die Vertrautheit mit der Problemdomäne voraus.

Das ist in Ordnung, da die Vertrautheit mit der Problemdomäne wahrscheinlich erforderlich ist, um den Code zu verstehen und zu pflegen, insbesondere in der Rolle von jemandem, der ihn "besitzt". Daher müssen Sie sich die Vertrautheit aneignen, anstatt Namen zu verlängern.

Aber es wäre schön, wenn der Code einige Hinweise als Sprungbrett liefern würde. Sogar ein Domain-Experte könnte vergessen, dass dK eine konische Konstante ist. Das Hinzufügen eines kleinen "Spickzettel" in einem Kommentarblock würde nicht schaden.

48
Kaz

Für bestimmte Variablen, die in der Problemdomäne bekannt sind - wie hier -, sind knappe Variablennamen sinnvoll. Wenn ich an einem Spiel arbeite, möchte ich, dass meine Spielentitäten Positionsvariablen x und y haben, nicht horizontalPosition und verticalPosition. Ebenso erwarte Schleifenzähler, die über die Indizierung hinaus keine Semantik haben, i, j, k.

19

Gemäß "Clean Code":

Variablennamen sollten:

  • Sei aufschlussreich
  • Desinformation vermeiden
  • Machen Sie sinnvolle Unterscheidungen
  • Sei aussprechbar
  • Durchsuchbar sein

Ausnahmen sind die sprichwörtlichen i,j,k,m,n wird für Schleifen verwendet.

Die Variablennamen, über die Sie sich zu Recht beschweren, haben nichts mit den oben genannten zu tun. Diese Namen sind schlechte Namen.

Als jede Methode muss kurz sein wird die Verwendung von Präfixen zur Angabe von Gültigkeitsbereich oder Typ nicht mehr verwendet.

Diese Namen sind besser:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Ein Kommentator sagt, dass dies bei langen Variablennamen zu komplex wäre:

enter image description here

Kurze Variablennamen machen es auch nicht einfach:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

Die Antwort sind lange Namen und Zwischenergebnisse bis Sie dies am Ende erhalten:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;
16

Es gibt zwei gute Gründe, Variablen im Legacy-Code nicht umzubenennen.

(1) Wenn Sie kein automatisiertes Refactoring-Tool verwenden, ist die Wahrscheinlichkeit, dass Fehler auftreten, hoch. Daher: "Wenn es nicht kaputt ist, reparieren Sie es nicht."

(2) Sie machen den Vergleich aktueller Versionen mit früheren Versionen unmöglich, um zu sehen, was sich geändert hat. Dies erschwert die zukünftige Wartung des Codes.

8
ddyer

Gibt es einen guten Grund, Variablen auf diese Weise zu benennen, oder bin ich berechtigt, sie auf aussagekräftigere Namen zu aktualisieren, wenn ich auf sie stoße?

Der Grund für die Verwendung kleinerer Namen liegt darin, dass der ursprüngliche Programmierer die Arbeit mit ihnen einfacher findet. Vermutlich haben sie das Recht, dies für richtig zu halten und nicht die gleichen persönlichen Vorlieben wie Sie. Persönlich würde ich finden ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... wenn ich sie in langen, komplexen Berechnungen verwenden würde. Je kleiner der mathematische Ausdruck ist, desto einfacher ist es oft, das Ganze auf einmal zu sehen. Wenn dies der Fall wäre, wären sie möglicherweise besser als dIn und dOut, sodass es kein sich wiederholendes D gab, das zu einem einfachen Tippfehler führen könnte.

Wenn es Ihnen andererseits schwerer fällt, damit zu arbeiten, schlagen Sie sich aus und benennen Sie sie in ihre längere Form um. Vor allem, wenn Sie für diesen Code verantwortlich sind.

5
GrandmasterB

Im Allgemeinen glaube ich, dass die Regel dafür sein sollte, dass Sie extrem kurze Variablennamen verwenden können, wenn Sie wissen, dass Personen, die mit dem Fachgebiet Ihres speziellen Codes "vertraut" sind, die Referenz dieses Variablennamens sofort verstehen. (Mit Ausnahme dieses Falls haben Sie ohnehin immer Kommentare) und dass die lokalisierte Verwendung der Variablen anhand des Kontextes ihrer Verwendung leicht erkannt werden kann.

Um dies zu erweitern, bedeutet dies, dass Sie sich nicht die Mühe machen sollten, Ihre Variablennamen zu verschleiern. Sie können jedoch Abkürzungen für Ihre Variablennamen verwenden, bei denen Sie wissen, dass nur Personen wahrscheinlich sind, die das zugrunde liegende Konzept Ihres Codes verstehen es trotzdem zu lesen.

Um ein Beispiel aus der realen Welt zu verwenden, habe ich kürzlich eine Javascript-Klasse erstellt, die einen Breitengrad einnimmt und Ihnen die Menge an Sonnenlicht angibt, die Sie an einem bestimmten Datum erwarten würden.

Um dies zu erstellen Sonnenuhr-Klasse , habe ich auf ein halbes Dutzend Ressourcen, den Astronomie-Almanach und Ausschnitte aus anderen Sprachen (PHP, Java, C usw.) verwiesen.

In fast allen verwendeten sie ähnliche identische Abkürzungen, die auf den ersten Blick absolut nichts bedeuten.

K, T, EPS, deltaPsi, eot, LM, RA

Wenn Sie jedoch Kenntnisse der Physik haben, können Sie verstehen, was sie waren. Ich würde nicht erwarten, dass jemand anderes diesen Code berührt. Warum also ausführliche Variablennamen verwenden?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Wenn Variablennamen nur vorübergehend sind, dh nur zum vorübergehenden Zuweisen eines Werts verwendet werden, ist es häufig nicht sinnvoll, eine ausführliche Version zu verwenden, insbesondere wenn der Kontext der Variablen verwendet wird erklärt seinen Zweck.

4
Laykes

Es gibt absolut; Oft reicht ein kurzer Variablenname aus.

In meinem Fall mache ich Wegpunktnavigation in meiner Senior Robotics-Klasse und wir programmieren unsere Roboter in KISS-C. Wir benötigen Variablen für aktuelle und Zielkoordinaten (x, y), (x, y) Entfernungen, aktuelle und Zielüberschriften sowie Drehwinkel.

Insbesondere bei x- und y-Koordinaten ist ein langer Variablenname völlig unnötig, und Namen wie xC (aktuelles x), yD (Ziel y) und pD (Ziel phi) reichen aus und sind am einfachsten zu verstehen in diesem Fall.

Sie könnten argumentieren, dass dies keine 'beschreibenden Variablennamen' sind, wie es das Programmiererprotokoll vorschreiben würde, aber da die Namen auf einem einfachen Code basieren (d = Ziel, c = aktuell), ist ein sehr einfacher Kommentar am Anfang die gesamte Beschreibung Sie benötigen.

1
George Gorski

Gibt es einen guten Grund, Variablen auf diese Weise zu benennen, oder bin ich berechtigt, sie auf aussagekräftigere Namen zu aktualisieren, wenn ich auf sie stoße?

Normalerweise werden komplexe Algorithmen in Matlab (oder einer ähnlichen Sprache) implementiert. Was ich gesehen habe, sind Leute, die nur den Variablennamen übernehmen. Auf diese Weise ist es einfach, Implementierungen zu vergleichen.

Alle anderen Antworten sind fast richtig. Diese Abkürzungen finden sich in Mathematik und Physik, außer dass sie nicht mit d beginnen (wie in Ihrem Beispiel). Variablen, die mit d beginnen, werden normalerweise benannt, um Differenzierung darzustellen.

In allen normalen Codierungshandbüchern wird empfohlen, Variablen nicht mit dem ersten Buchstaben zu benennen, der den Typ darstellt (wie in Ihrem Fall), da das Durchsuchen des Codes in allen modernen IDEs so einfach ist.

0
BЈовић

Ich kann mir einen Grund vorstellen, warum Variablennamen ziemlich kurz sind.

Die Kurznamen sind mit einer kürzeren Augenspanne leicht zu lesen, daher eine kurze Aufmerksamkeitsspanne.

Wenn ich mich zum Beispiel daran gewöhnt habe, dass svdb "in der Datenbank speichern" bedeutet, wird die Scanrate des Quellcodes besser, da ich nur 4 Zeichen schnell scannen muss, anstatt beim Lesen von SaveToDatabase (14 Zeichen, die Dinge werden schlimmer) für komplexere Operationsnamen). Ich sage "Scannen", nicht "Lesen", da dies einen großen Teil der Analyse des Quellcodes ausmacht.

Dies kann beim Durchsuchen einer großen Menge an Quellcode zu guten Leistungssteigerungen führen.

Außerdem hilft es dem faulen Programmierer nur, diese Kurznamen beim Schreiben von Code einzugeben.

Natürlich wird erwartet, dass alle diese "Abkürzungen" an einer Standardposition im Quellcode aufgeführt sind.

0
Amol

Um das, was @zxcdw gesagt hat, etwas anders zu formulieren und im Hinblick auf den Ansatz näher zu erläutern:

Die Funktionen sollten pure, kurz und eine perfekte Verkapselung einiger Funktionen sein: Black-Box-Logik , unabhängig davon, ob sie seit 40 Jahren unberührt sind, werden sie weiterhin verwendet Machen Sie den Job, für den es entwickelt wurde, denn seine Schnittstelle (rein und raus) ist solide, auch wenn Sie nichts von seinen Interna wissen.

Dies ist die Art von Code, die Sie schreiben möchten: Dies ist Code, der Bestand hat und einfach zu portieren ist.

Wo nötig, komponiere Funktionen aus anderen (Inline-) Funktionsaufrufen , um den Code feinkörnig zu halten.

Mit einem entsprechend beschreibenden Funktionsnamen (bei Bedarf ausführlich!) Minimieren wir nun die Wahrscheinlichkeit einer Fehlinterpretation dieser verkürzten Variablennamen, da der Umfang so klein ist.

0
Engineer