Abkürzung von Variablennamen [geschlossen]

Ich habe immer Schwierigkeiten, Variablennamen abzukürzen. Gibt es einen Standard für die Abkürzung von Variablennamen?

Der Standard, den ich verwende, besteht darin, Variablennamen nicht abzukürzen, es sei denn, die Abkürzung ist besser lesbar als die Vollversion ( iz. B. für Iterationsindizes). Wir benennen Dinge, damit wir kommunizieren können. Das Abkürzen von Variablennamen verringert normalerweise nur die Kommunikationsfähigkeit.

Ich bin kein C # -Programmierer, daher kann ich Ihnen nicht viele Ratschläge zu C # -Konventionen geben. Aber ich habe einige Gedanken über Abkürzungen.

Als ich älter und erfahrener geworden bin, habe ich festgestellt, dass ich immer weniger abkürze. Ich gebe zu, dass ich zu Beginn des Programmierens keine sehr gute Schreibkraft war. Das habe ich seitdem besser gemacht;). Ich werde für Variablen mit sehr begrenztem Umfang frei abkürzen, so dass ich ihre gesamte Lebensdauer auf einem Bildschirm sehen kann. Aber ansonsten ziehe ich es vor, es nicht zu vermeiden, wenn ich es vermeiden kann - ich kürze nie ab, um das Tippen zu speichern.

Ich versuche immer noch, meine Zeilen unter 80 Zeichen zu halten. Ich bin mir nicht sicher, ob das heutzutage Sinn macht, aber es ist eine alte Gewohnheit. Ich werde also abkürzen, wenn ein Variablenname sonst sehr lang sein wird. Aber bevor ich das tue, werde ich versuchen, einen prägnanteren Namen zu finden, der ebenso klar ist - alles andere, was gleich kürzer ist, ist besser (wenn man von der erweiterten Form spricht).

Wo Sie abkürzen, ist es meiner Meinung nach am wichtigsten, dass Sie in einer bestimmten Codebasis und über verwandte Codebasen hinweg immer auf die gleiche Weise abkürzen. Ihr erster Instinkt ist wahrscheinlich der, mit dem Sie gehen, da Sie sich am leichtesten daran erinnern können, aber es kann sich lohnen, mit anderen Personen über dasselbe Projekt zu sprechen. Heutzutage arbeite ich hauptsächlich mit einem anderen Programmierer in einem offenen Büro voller Nicht-Programmierer. Sie halten uns für verrückt, weil wir häufig ausführliche Diskussionen darüber führen, wie verwandte Variablennamen konsistent abgekürzt oder Parameter in Funktionsaufrufen usw. konsistent geordnet werden können. Die Benennung ist jedoch wichtig, selbst für zwei Personen. In größeren Teams wird es noch wichtiger. Eine Sache, bei der ich ziemlich religiös bin, ist das Beheben von Inkonsistenzen in solchen Dingen, sobald ich sie entdecke.

EDIT: Einige Abkürzungen sind allerdings gut, denke ich. In meinem aktuellen Job hat ein Großteil des Codes, den ich schreibe, mit der Auswertung von Splines und anderen parametrischen Funktionen bei bestimmten Parameterwerten zu tun. Unsere Codebasis ist in dieser Hinsicht tatsächlich inkonsistent. Ich weiß, dass u an einigen Stellen verwendet wird und param (eine Abkürzung selbst) an anderen verwendet wird. U ist eine allgemein verstandene Abkürzung für Parameter in diesem Bereich, daher denke ich, wir sollten dies durchgehen und konsistent machen. Ich würde mit jedem von u, param oder parameter in Ordnung sein. Wir verwenden sie so oft, dass es unwahrscheinlich ist, dass es zu Verwirrung kommt, solange wir nur eine verwenden . Aber ich würde dich bevorzugen.

Es ist jedoch schlimmer als das - wir haben tatsächlich verschiedene Arten von Parametern. Und wir haben mehr als einen Namen für einige von ihnen.

Der Grund dafür ist das Lehrbuch. Es stellte sich heraus, dass wir zwischen sechs Parameterräumen abbilden mussten - die Gründe sind kompliziert, aber im Grunde mussten wir Parameter haben, die dem Parameterraum, dem normalisierten Parameterraum, dem Bogenlängenraum, dem normalisierten Bogenlängenraum, dem stückweisen Raum und dem normalisierten Raum entsprachen stückweise Raum. Wir haben zunächst nicht realisiert, dass wir zwischen all diesen Räumen hin und her kartieren müssen. Und wir waren inkonsistent darin, wie wir Parameter benannten, die Punkte in diesen Räumen beschreiben.

Dies passiert manchmal - Ihre App wird erwachsen und Sie tun einige inkonsistente Dinge, während Sie sie erweitern. Das Wichtigste ist, dass Sie erkennen, dass Sie unordentlich geworden sind, und hineingehen und es reparieren, bevor die Unordnung alles andere infiziert und Sie mit einem Haufen Trümmer enden.

Die vry rsn w nicht bbrvt st mk sr th cd s rdbl nd mntnbl z

int accountBalanceInSavings

-> könnte mit abgekürzt werden

int accBalInSaving

Beachten Sie, dass zwei der vier Wörter kurz sind (account-> acc und Balance-> Bal), die anderen beiden jedoch nicht. Welche Regel hier angewendet wird - die ersten 2 Wörter abbrivieren, es sind keine "Wörter über 6 Buchstaben", weil 2 7 Buchstaben waren und einer nicht war.

So könnte / sollte es 'accBalInSav' sein, yuk yuk yuk .......

Meine Erfahrung als Programmierer, die älter und weiser werden, verkürzen sie immer weniger. In meinem Alter versuchen wir wahrscheinlich, die Sünden unserer Jugend wiedergutzumachen .....

Denken Sie daran, dass Code einmal geschrieben wird (ok, viele mehr als einmal) und tausende Male gelesen wird.

Es gibt eine ähnliche Frage zu einzelnen Zeichennamen: Verwenden einzelner Zeichen für Variablennamen in Schleifen / Ausnahmen .

Meine Antwort damals wie heute ist, sie kurz zu halten, wenn der Umfang klein ist. Beispielsweise ist ein Parameter einer Kurzfunktion besser lesbar, wenn er kurz ist und weniger Platz benötigt. Eine klassenweite Variable sollte sehr beschreibend sein.

Steve McConnells klassisches Buch Code Complete eignet sich hervorragend für solche Dinge.

Ich glaube nicht, dass es offizielle oder gemeinsame Regeln für Abkürzungen gibt. In der Regel wird von jedem Einzelnen und innerhalb jedes einzelnen Projekts ein Abkürzungssystem entwickelt. Es kann bestimmte Regeln für die Quellcode-Richtlinien eines Unternehmens geben, diese variieren jedoch auch je nach Unternehmen.

Nebenbei bemerkt, warum überhaupt abkürzen? Das führt dazu, dass nur Sie verstehen, was die Abkürzungen bedeuten. Verwenden Sie vollständige und beschreibende Namen für Variablen. Dies führt zu einem selbstdokumentierenden Code.

Wenn Sie Zweifel haben, formulieren Sie es.

Der Punkt eines Variablennamens ist so, dass die Bedeutung des Codes klarer wird. Wenn die Abkürzung nicht sehr offensichtlich ist, können Sie auch die kleinstmögliche verwenden. Variablennamen und Funktionsnamen sind normalerweise die einzigen Teile der menschlichen Sprache im Code und dienen daher sowohl als "Orientierungspunkte" für das menschliche Auge, um relevante Teile des Codes (oder in einer großen Codebasis Werkzeuge wie grepoder ack) als auch als Hinweise zu finden zum Verständnis.

Wenn die nächste Person Ihren Code liest, wird sie Ihnen dafür danken. Diese Person könnte in einem Jahr Sie sein. Ich habe viel Code, den ich leider abkürzen muss, deshalb versuche ich heutzutage, ihn zu vermeiden.

Es ist in Ordnung abzukürzen, wenn ...

... Wenn die abgekürzte Form von mehr als nur den Personen, die an Ihrem Projekt arbeiten, in gesprochenem oder geschriebenem Englisch verwendet wird (viele Wörterbücher enthalten diese Art von Informationen neben dem von ihnen definierten Begriff).

var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation

... Wenn sich die Abkürzung eindeutig auf ein einzelnes Konzept bezieht und sofort von jemandem erkannt wird, der mit der Codebasis nicht vertraut ist. Auch dann hilft ein Kommentar oder eine Dokumentation.

var auth = user.auth;
if (auth) // If the user is authenticated?
          // If the user is authorised to do something?
          // If the authentication function exists for that user group?
          // If some setting called auth is turned on for that user?
          // If the user is the author of the document in question?
          // If the user has some authority?

var attrNames = retrieveAttrs();
if (attrNames)  // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!

const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name

... Wenn der Variablenname nur in einem einzelnen Bereich oder einer kleinen Funktion vorhanden ist und Sie nicht erwarten, dass der Benutzer aus dem Namen eine Bedeutung ableitet, verwenden Sie ein einzelnes Zeichen. In solchen Fällen iund jsind üblich.

foreach $i (1..10) { say $announcement->[$i] }

... Wenn Sie eine Schnittstelle schreiben (dh keinen Variablennamen, also außerhalb des Rahmens der Frage, nur erwähnt, weil Variablennamen und Schnittstellen, die sie festlegen, häufig dasselbe Vokabular verwenden), können in diesem Fall andere Regeln gelten, zum Beispiel:

some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done"    # if you can spare -m

... Wenn Ihre Codebasis im selben Projekt mehrmals auf dasselbe Konzept verweisen muss und wenn die Abkürzung in einem Styleguide für dieses Projekt definiert werden kann und wenn sie eindeutig ist. Wenn Ihr Projekt nicht groß genug für einen Styleguide ist, ist es nicht groß genug, damit es sich lohnt.

Ich werde diesem Beispiel kein Codebeispiel geben, da es per Definition nur in einem großen Projekt funktioniert, aber siehe auch den nächsten Punkt:

... bei der Arbeit an einem etablierten Projekt mit mehreren Mitwirkenden und einem Styleguide, der Abkürzungen vorschreibt. In diesem Fall sollten Sie nur gemäß dem Styleguide abkürzen, aber auf Probleme achten und mit Kommentaren versehen sein (z. B. "Dies ist eine Liste von Attributnamen als Zeichenfolgen").

Typen sollten mit "_t" enden. Rohe Strukturdefinitionen in "_struct"

- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt

Ein letzter Gedanke: Wenn Sie immer noch unannehmbar lange Variablennamen haben (z. B. bestehend aus vier oder mehr semantischen Einheiten wie totalAfterTaxInLocalCurrency), kann dies ein Symptom dafür sein, dass Ihr Code versucht, in einem einzigen Bereich zu viel zu tun, und seine Funktionen überarbeitet werden müssen out oder Ihre Variablen werden möglicherweise logischer in einem einzelnen Objekt verwaltet.

Der Grund, warum wir Variablen abkürzen, besteht darin, die Eingabe großer Variablen zu beenden. Gleichzeitig sollte die abgekürzte Variable so explizit sein, dass Sie verstehen können, was sie enthält, anstatt dorthin zurückzukehren, wo sie zuerst deklariert oder instanziiert wurde. Also zum Beispiel:

int accountBalanceInSavings

-> könnte mit abgekürzt werden

int accBalInSaving

---> aber abkürzen auf

int accBal

Wäre definitiv keine gute Option, da man nicht verstehen könnte, was die Variable enthält, wenn man sie nur betrachtet.

Sie sollten Dinge nicht abkürzen, um sie abzukürzen, Sie sollten es für Ihre / andere Bequemlichkeit tun, aber wenn Sie wollen, dann ist eine allgemeine Regel, die ich für die Abkürzung habe, wenn ein Wort mehr als vier oder fünf Buchstaben lang ist Ich werde es auf die ersten drei signifikanten Buchstaben dieses Wortes verkürzen, z.

int damagePerSecond;

könnte abgekürzt werden

int dmgPerSec;

oder wenn Sie es so kurz wie möglich wollen,

int dps;