Lohnen sich Typ- und Umfangspräfixe als Namenskonventionen?

Als ich vor kurzem meinen ersten Job als Softwareentwickler angefangen habe, wurde mir ein wenig gesagt, dass ich keine Namenskonventionen in meinem Code befolgen musste. Code, der von Gruppen geschrieben wurde, die an anderen, größeren Projekten arbeiteten, folgte Namenskonventionen, aber da ich dazu gebracht wurde, eine neue, eigenständige Anwendung zu schreiben, war das Gefühl, dass es nicht besonders wichtig war. Es war das Letzte, was ich mir Sorgen machte, also nahm ich einfach die bestehende Konvention und lief damit.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Aber lohnt es sich wirklich? Es fällt mir schwer, den Nettoeffekt zu beurteilen, den eine solche Namenskonvention auf das Verständnis und die Erkennung von Fehlern hat, aber visuell sieht es einfach irgendwie hässlich aus. Außerdem scheint es ziemlich blöd zu sein, jede Klasse und Datei im Projekt mit dem Namen cSomething zu haben.

Ich bin nicht der Illusion verfallen, dass es im Vergleich zu Dingen, die einen offensichtlichen Unterschied machen, wie den von Ihnen verwendeten Algorithmen und Architekturen, eine große Sache ist. Aber jede Konvention, die sich auf jede Codezeile auswirkt, die ich schreibe, scheint es wert, richtig zu sein.

Was ist für Sie die eleganteste und effektivste Namenskonvention, wenn überhaupt eine verwendet werden muss? Bezeichnet es Art und / oder Umfang?

Joel Spolsky hat einen Artikel darüber geschrieben, warum es ungarische Notationen gibt und wofür sie gedacht sind, um Ihre Frage zu beantworten.

Präfixe wie tbl für eine Datenbanktabelle, int für eine Ganzzahl usw. sind im Allgemeinen nicht nützlich - es ist trivial herauszufinden, was aus dem Kontext oder aus Ihren Entwicklungstools in diesen Fällen stammt. So etwas wie imp für imperiale Maße und met für metrische Maße ist viel sinnvoller, weil man sonst nur sehen kann, dass es sich um Gleitkommazahlen handelt.

area = width * height

sieht dabei ganz gut aus

impArea = metWidth * impHeight

zeigt Ihnen sofort, dass etwas nicht stimmt.

Persönlich verwende ich nur beschreibende Variablennamen. $ number_of_items ist offensichtlich eine Ganzzahl. $ input_file_handle, $ is_active und $ encrypted_password haben offensichtliche Typen sowohl hinsichtlich des Sprachdatentyps als auch des semantischen Typs.

Was Sie beschreiben, heißt ungarische Notation . Früher galt es als Best Practice, wird aber heute allgemein verpönt.

Der Wikipedia-Artikel enthält einen Abschnitt über seine Vor- und Nachteile.

Ja, Präfixe können nützlich sein, aber ich habe ein paar Vorschläge:

Wenn Ihr gesamtes Team dieselben Konventionen verwendet, werden sie viel nützlicher. Sie alleine zu benutzen ist weniger hilfreich.

Kopieren Sie in stark statisch typisierten Sprachen nicht nur den Typ einer Variablen. Beispiel: "bSubscribed" ist ein falscher Name für eine boolesche Variable in C # oder Java, da Ihre IDE bereits weiß, um welchen Typ es sich handelt. In C hingegen, dem ein Boolescher Typ fehlt, wäre dies eine nützliche Information.

In C # und Java können Sie ein Präfix in Betracht ziehen, um anzuzeigen, dass ein Objekt möglicherweise null ist. Oder dass ein String mit HTML-Escapezeichen versehen wurde. Oder dass es sich um einen regulären Ausdruck oder eine SQL-Anweisung handelt. Oder dass ein Array sortiert wurde. Nutze deine Vorstellungskraft.

Im Grunde geht es darum, sich zu fragen, was ein Variablenname Ihnen sagen soll, und das hängt stark von der Domäne und der Sprache ab, in der Sie arbeiten.

Es gibt ein paar verschiedene "Stile" von Namenskonventionen, und die meisten von ihnen haben einen gewissen Wert darin, Code verständlich zu machen.

Was bei Weitem wichtiger ist: Verwenden Sie beschreibende Namen für Variablen und Funktionen. In Ihrem Beispiel mit "sum", "weight" und "value" möchten Sie möglicherweise aussagekräftigere Namen angeben: "totalCost", "lumberWeight", "lumberValuePerOunce" (ich mache hier einige Annahmen)

Konventionen wie das Voranstellen von Variablennamen mit einem Zeichen, das den Typ kennzeichnet, lenken in den meisten modernen Sprachen ab.

Die meisten .NET-Entwickler befolgen die Designrichtlinien von Microsoft ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ), die Java ziemlich ähnlich sind (Hauptunterschied ist, dass Microsoft Pascal Case für Mitgliedsnamen bevorzugt, während Java bevorzugt Kameltasche).

Abgesehen davon würde ich sagen, dass Ihr Codebeispiel aufgrund des zusätzlichen Rauschens, das Sie hinzugefügt haben, weitaus weniger lesbar ist.

Ich finde, dass der Coding-Style-Guide von Google größtenteils ziemlich gut ist. Da Ihnen gesagt wurde, dass Sie jeden Stil verwenden können, den Sie mögen, sollten Sie sich dies zunächst einmal ansehen und einen auswählen.

Das Präfixieren von Variablennamen mit Datentypen (insbesondere primitiven Datentypen) erhöht das visuelle Rauschen sowie das Risiko, dass aus einer ansonsten geringen Änderung eine Umbenennung mit einem Urknall wird.

Was den ersten Punkt betrifft, ist "intStudentCount" wirklich deutlicher als zB "numberOfStudents"? Wäre "invoiceLineItems" nicht mindestens so informativ wie "aobjItems"? (Der Datentyp sollte sich auf die Bedeutung der Daten in der Problemdomäne beziehen, nicht auf die Darstellung auf niedriger Ebene.)

Was passiert beim zweiten Punkt, wenn z. B. eine vorzeitige Auswahl von int durch long oder double ersetzt wird? Schlimmer noch, was passiert, wenn eine konkrete Klasse in eine Schnittstelle mit mehreren implementierenden Klassen umgestaltet wird? Jede Praxis, die die Belastung durch realistische Wartungsszenarien erhöht, erscheint mir fraglich.

Dies kann auch davon abhängen, warum Sie dem Namen ein Präfix voranstellen und nicht nur, womit Sie ihn voranstellen.

Als Beispiel neige ich dazu, ein Präfix von 1 bis 2 Buchstaben für die Namen der Steuerelemente in einem Formular zu verwenden. Es liegt nicht daran, dass ich nicht weiß, dass der Compiler leicht die richtige Klasse für die Schaltfläche finden kann (als Beispiel), aber ich neige dazu, zuerst große Formulare zu entwerfen und dann den größten Teil des Codes zu schreiben.

Mit dem Präfix bt für die Schaltflächen können Sie die richtige Schaltfläche später leicht finden, anstatt viele Namen durcheinander zu bringen.

Ich benutze jedoch keine Präfixe für die Benennung von Variablen, weder für den Typ (der im Allgemeinen sowieso nicht so nützlich ist), noch für die Bedeutung, den Kontext oder die Einheit (was die ursprüngliche Idee hinter der ungarischen Notation ist).

Aus meiner Sicht kommt es auf die Sprache und die Größe des Projekts an. Ich bin noch nie so weit gegangen, Typpräfixe für alle meine Variablen zu verwenden, aber Sie möchten sie eindeutig benennen.

In einer statisch getippten Sprache, wie der, die Sie verwenden, wird die ungarische Notation umso unwichtiger, je besser ich mich mit dem Typensystem fühle. In Java oder C # und insbesondere in Haskell würde ich nicht einmal über das Hinzufügen dieser Präfixe nachdenken, da Ihre Tools Ihnen den Typ eines bestimmten Ausdrucks mitteilen können und die meisten Fehler auffangen, die aus einem Missverständnis eines Typs resultieren.

Präfixe sind häufig sinnvoll für Objekte, beispielsweise in einer Form, in der möglicherweise 20 Textfelder vorhanden sind, in denen sie alle als tbSomethingsinnvoll bezeichnet werden.

Vor allem für Werttypen halte ich es jedoch nicht für sinnvoll.

Angenommen, Sie hatten:

short shortValue = 0;
//stuff happens

Monate später müssen Sie es ändern - ein Short ist nicht groß genug. Jetzt hast du:

int shortValue = 0;
//stuff happens

Wenn Sie jetzt nicht auch den Namen der Variablen ändern (in diesem Fall besteht ein höheres Risiko, den Code zu beschädigen, als den Typ zu ändern), ist der Code jetzt verwirrend.

Es ist besser, einen Namen zu haben, der beschreibt, was er enthält:

int loopCounter = 0;
//stuff happens

Wenn sich das später ändern muss: kein Problem.

Es gibt vielleicht mehr Argumente für diese Konventionen in dynamisch typisierten Sprachen oder solchen ohne IDE.

Ich war schon immer geneigt, eine 2 bis 4-stellige Abkürzung für den Typ vor der Variablen selbst zu verwenden. Manchmal scheint es mühsam, aber wenn Sie mit komplexen Datentypen oder Situationen arbeiten, wird es vorteilhaft. Ich denke, es fällt in die untere Kategorie der Kamelkästen.

Wenn Sie sich Ihr Beispiel oben ansehen, wäre es leicht umgerüstet:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Arrays haben immer ein a vor dem Typ, um das Array zu bezeichnen. Dies ermöglicht mir auch, ähnliche Variableninstanzen zu gruppieren. Zum Beispiel kann ich verwenden ...

taStore.Fill(dtStore);

... was darauf hinweist, dass mein Store TableAdapter die Store DataTable füllt.

Ich habe immer versucht, mich an das Grundprinzip zu halten, dass Präfixe und / oder Suffixe nur eingefügt werden sollten, wenn der Code besser lesbar ist (wie im Klartext).

Je weniger kryptisch, desto besser ...

Warum eine Methode wie diese haben:

public boolean connect( String h, int p );

Wenn Sie so etwas haben können:

public boolean connect( String hostName, int port );

Darüber hinaus verfügen die IDEs heute über ein leistungsfähiges Werkzeug zum Umgestalten von (insbesondere Java-) Variablen, Methodennamen, Klassen usw. Die Idee, die maximale Information mit der geringsten Menge an Zeichen auszudrücken, ist einfach altmodisch.