Bin ich unmoralisch, wenn ich einen Variablennamen verwende, der sich nur durch Groß- und Kleinschreibung von seinem Typ unterscheidet?

95

Nehmen Sie zum Beispiel diesen Code:

var person = new Person();

oder für Sie Pythonistas:

person = Person()

Mir wird ständig gesagt, wie schlimm das ist, aber ich habe noch kein Beispiel für die Unmoral dieser beiden Codezeilen gesehen. Für mich ist eine Person eine Person und der Versuch, ihr einen anderen Namen zu geben, ist Zeitverschwendung. Ich nehme an, in den Tagen vor dem Hervorheben der Syntax wäre dies eine große Sache gewesen. Aber heutzutage ist es ziemlich einfach, einen Typnamen von einem Variablennamen zu unterscheiden. Heck, es ist sogar leicht, den Unterschied hier auf SO zu sehen.

Oder fehlt mir etwas? In diesem Fall wäre es hilfreich, wenn Sie ein Beispiel für Code angeben könnten, der Probleme verursacht.

Jason Baker
quelle
Ich habe mich immer darüber gewundert. Gute Frage!
William Brendel
18
Eine Person anzurufen ist einfach grausam. Was ist los mit "Bob"?
Sam Meldrum
17
Vergessen wir nicht, bevor var die Zen-Schönheit von Person person = new Person () hatte;
Jamie Ide
1
@ Jamie nennst du statische Eingabe zenartig?
Orokusaki
Ich möchte noch eine Ebene tiefer in diese Frage eintauchen: Ist es unbestreitbar falsch, dies zu tun Person Person=new Person();? Wie in The Question angegeben, leben wir in Zeiten solch unglaublicher Syntaxhervorhebung und Kontexterkennung, dass mein Compiler sich nie darüber beschwert hat, dass ich genau das getan habe. Ich liebe meine Variablen CamelCased einfach - warum sollte ich das nicht tun (in Situationen, in denen Person Personeine allgemeine und einzige Instanziierung der Klasse vorliegt und kein Konflikt vorliegt oder möglich ist)?
Robert Synoradzki

Antworten:

94

Was ist der Grund für diejenigen, die Ihnen sagen, dass dies schlecht ist? Ich mache das die ganze Zeit. Dies ist die einfachste und aussagekräftigste Methode, um eine einzelne Variable eines Typs zu benennen. Wenn Sie zwei PersonObjekte benötigen, können Sie personsinnvolle Adjektive wie voranstellen

fastPerson
slowPerson

sonst einfach

person

geht es mir gut

Andrew Hare
quelle
8
"Was ist der Grund für diejenigen, die dir sagen, dass das schlecht ist?" - Keine Ahnung. Deshalb habe ich dieses Thema begonnen. :-)
Jason Baker
Natürlich mussten Sie nie in den Code eines anderen kommen. Ich weiß, dass, wenn ich von einem Programmierer, der das Unternehmen längst verlassen hat, einen neu entdeckten Fehler in mehrjährigem Code untersuchen muss - alles, was mich daran hindert, mich hochzufahren, ist Zeit, das Problem nicht zu beheben. Wenn eines dieser Hindernisse darin besteht, herauszufinden, was eine Instanz und was eine Klasse ist, nur weil ein Programmierer nicht die Mühe hat, "var currentPerson = New Person ()" zu sagen; dann ist das nutzlose, verschwendete Zeit. ... und wenn Ihre Kunden auf eine Lösung warten, ist Zeit von entscheidender Bedeutung.
David
3
@ David - Du hast mich erwischt! Ich wusste, dass das Codieren in einem Vakuum früher oder später seinen hässlichen Kopf aufrichten würde :) Im Ernst - es fällt mir schwer zu glauben, dass Sie gestolpert sind, wenn Sie aufgrund dieser Namenskonvention nicht zwischen Typen und ihren Instanzen unterscheiden können.
Andrew Hare
2
@ David - das sollte das Problem für das Code-Analyse-Tool sein. Aus diesem Grund gibt es in Python die Konvention, dass Typen mit Großbuchstaben beginnen.
ilya n.
69

Ich verwende dieses Muster häufig in Methodensignaturen. Wenn ich keinen alternativen beschreibenden Namen als IMHO angeben kann, ist daran nichts auszusetzen.

Was falsch ist, wäre, wenn Sie zwei Arten Person und Person haben, dann ist das sehr sehr falsch.

JoshBerke
quelle
1
"Was falsch ist, wäre, wenn Sie zwei Arten Person und Person haben, dann ist das sehr, sehr falsch." - Das macht für mich total Sinn.
Jason Baker
1
Wenn Sie eine API erstellen, kann VB den Code nicht verarbeiten, da die Groß- und Kleinschreibung nicht berücksichtigt wird.
JoshBerke
1
Hey, im Fall einer API stören Sie sich an öffentlichen Methodennamen oder -eigenschaften, nicht an Variablennamen, da letztere nicht dem Clientcode ausgesetzt sind. Was Jasons Frage betrifft, verwende auch ich diese Benennung die ganze Zeit. Absolut nichts falsch daran.
Frederick The Fool
1
Genau mein Punkt Frederick, warum es eine schlechte Idee ist, zwei Typen zu haben, die sich nur im Basisfall unterscheiden
;-)
1
Auch wenn es nicht falsch ist, ist der Code schwerer zu lesen. Lesbarkeit ist auch wichtig.
J3r3myK
45

Ich benutze es die ganze Zeit für temporäre Objektreferenzen. Ich würde es wie die Pest für primitive Datentypen vermeiden.

Person person = new Person(); // okay

int Int = 42; // pure evil
Bill die Eidechse
quelle
Wenn es wirklich keine semantische Bedeutung gäbe, könnte ich ein Grundelement angeben, das ich i oder s verwenden würde, abgesehen von Schleifenindizes, kann ich mir kein anderes solches Szenario vorstellen.
AnthonyWJones
1
Ich würde empfehlen, i nicht zu verwenden, insbesondere wenn Sie Code mit einer Schleife schreiben. i wird fast allgemein als Name einer Schleifenvariablen angesehen.
Jason Baker
3
Einverstanden. Ein Variablenname mit einem Buchstaben schreit: "Ich bin vorübergehend." Schleifenindizes sollten i, j, k sein, alle anderen sollten a, b, c, x, y, z oder ein anderer Buchstabe sein, der nicht mit etwas anderem verwechselt werden kann, wie l und o.
Bill the Lizard
Bravo! 42 ist einfach zu viel. :)
Vishal Seth
18

Wenn jemand sagt, dass das böse ist, fragen Sie ihn, ob dies besser ist:

var abc = new Person();
Chris
quelle
2
@ Chris: genau! Oder noch besser: var temp = new Person();(Haftungsausschluss: Ich weiß, dass es wirklich Orte gibt, an denen temporäre Variablen einmal verwendet werden können, aber so oft wie nicht, wenn ich dies in einem Code von jemandem sehe, ist der Autor einfach nie wieder dazu gekommen, der Variablen einen geeigneten Namen zu geben, und es kann sein sei auch "abc".)
Dinah
15

Wenn die Person im Kontext eine allgemeine Person ist, dann ist "Person" ein wirklich guter Name. Wenn die Person eine bestimmte Rolle im Code hat, ist es natürlich besser, sie anhand der Rolle zu benennen.

PEZ
quelle
9

Ich nehme an, ich werde dafür herabgestimmt, aber ...

Wir Programmierer haben gerade ein Jahrhundert erlebt, in dem epischer Mord und Gier erlebt wurden. Wir sind wirklich gesegnet, wenn das Unmoralischste, was wir tun können, darin besteht, eine Variable zu benennen.

Mike Dunlavey
quelle
6
Wenn die moralischen Entscheidungen, die wir treffen können, so unbedeutend sind, werden wir verflucht. Ich bin mir nicht sicher, ob sich meine Begräbnisrede auf meinen Codierungsstil konzentrieren soll. Ich möchte zumindest kurz erwähnen, dass ich Teil einer Familie bin.
David Thornley
1
@ David: Schon wieder richtig. Mit meinem ersten Enkelkind auf dem Weg ist es wohl banal, aber es ist mir egal, was für eine Welt wir weitergeben.
Mike Dunlavey
8

Ich denke nicht, dass es notwendigerweise "schlecht" ist, aber wenn Sie es qualifizieren können, um ihm mehr Kontext zu geben, wie zum Beispiel, um welche Art von Person es sich handelt (Sie haben es nur mit einer von vermutlich vielen möglichen Personen zu tun), dann wählt jemand anderes es aus bis kann besser verstehen.

Tim Almond
quelle
6

Jason - Ich bin mir nicht sicher, wer dir gesagt hat, dass das schlecht ist. Eine Reihe von Autoren verwenden dies als Standardmethode, um eine Instanz (Kleinbuchstaben) einer Klasse (großgeschrieben) auszudrücken .

Ich benutze dies ziemlich oft, da ich feststelle, dass die Variable mit dem unteren Gehäuse mir tatsächlich nicht nur mitteilt, dass dies eine Instanz ist, sondern auch den Namen der Klasse.

Sofern nicht jemand ein solides gegenteiliges Argument hat, werde ich dies auf jeden Fall fortsetzen.

Mark Brittingham
quelle
6

Der Grund, warum es als schlecht angesehen wird, ist, dass Sie, wenn Sie in Zukunft 2 Personen benötigen, möglicherweise Code erhalten, der aussieht.

Person Person = neue Person ();

Person person2 = neue Person ();

Das würde dann an "Bad" grenzen. In diesem Fall sollten Sie jedoch Ihre ursprüngliche Person umgestalten, um zwischen den beiden zu unterscheiden.

In Ihrem Beispiel ist der Variablenname "Person" ein perfekt beschreibender Name für das Objekt "Person". Daran ist also überhaupt nichts auszusetzen.

Robin Day
quelle
3

Ich sage Name für das, was es ist: Wenn die Variable eine Person mit 2 Hunden darstellt, nennen Sie es personWith2Dogs. Wenn die Variable einen kurzen Gültigkeitsbereich hat (wie eine Schleifenvariable), ist die Person in Ordnung.

Mitch Wheat
quelle
3

Ich benutze das oft in meinem Code und glaube nicht, dass daran etwas falsch ist. Das heißt, ich würde es (wahrscheinlich) nicht länger in einer Methode als beispielsweise einem Bildschirm verwenden, und wenn es mehrere Instanzen der Person-Klasse gibt. Nennen Sie sie auf keinen Fall person1, person2, person3 ... verwenden Sie stattdessen etwas Beschreibenderes wie person_to_del, person_to_ban, person_to_update usw.

kmelvn
quelle
3

Nicht unmoralisch, aber eine globale Suche findet beides Personund personwenn Sie die Groß- und Kleinschreibung nicht aktivieren. Ich bevorzuge ein Präfix, um das globale Suchen / Ersetzen zu vereinfachen, aber absolut NICHT ungarisch oder etwas Langes / Kompliziertes. Also benutze ich ...

Personfür die Klasse / den Typ aPersonfür eine lokale Variable thePersonfür einen Methodenparameter myPersonfür eine Instanzvariable ourPersonfür eine Klassenvariable

In seltenen Fällen kann ich pin einem lokalen Kontext verwenden, in dem ich VIELE Referenzen habe, aber das gilt normalerweise nur für Schleifenindizes und dergleichen.

Rob Williams
quelle
3

Es hängt davon ab, ob.

Wenn Sie einen strengen Großschreibungsstil haben, also Variablen in Kleinbuchstaben beginnen (und entweder under_scores oder camelCase für Wortumbrüche verwenden) und Klassen mit Großbuchstaben beginnen, ist es offensichtlich, dass Person eine Variable und Person eine Klasse ist, und wenn jemand dies versteht scheinen sie nicht in überlappenden Namespaces zu sein. (Ebenso werden Menschen fast nie zwischen dem Verb oder Substantiv "polnisch" und dem Adjektiv "polnisch" verwechselt.)

Wenn Sie keinen solchen Stil haben, haben Sie zwei Namen, die leicht verwechselt werden können und sich nur für den Fall unterscheiden. Das ist schlecht.

David Thornley
quelle
Hallo nochmal David. Ich kann mich nicht erinnern, ob Sie derjenige sind, der einen meiner Beiträge bearbeitet hat, weil ich "pollish" geschrieben hatte, oder war es "polish", als ich etwas reiben wollte, bis es glänzt? Na
ja
Ich glaube nicht, dass ich eine solche Bearbeitung vorgenommen habe, also war es wahrscheinlich jemand anderes. Übrigens ist es "polnisch".
David Thornley
2

Was sind die genauen Argumente, die diese Leute verwenden?

Wenn Sie die Person nicht als Variablennamen verwenden können, können Sie das Präfix 'a' hinzufügen.

aPerson = Person()
Gerrie Schenck
quelle
2
Das wäre meiner Meinung nach schlimmer. Es ist schwerer zu lesen und enthält keinerlei zusätzliche Informationen.
Joachim Sauer
Ja, aber zumindest unterscheidet sich der Name vom Klassennamen, was sie offensichtlich wollen.
Gerrie Schenck
Das würde den Buchstaben des Gesetzes folgen, aber definitiv nicht dem Geist.
Joachim Sauer
1
+1, ich verwende thePerson für Parameter und myPerson für von mir verwaltete Einheimische.
Amy B
2

Ich denke, was du tust, ist in Ordnung. Ich denke im Allgemeinen ist es wichtig, Kodierungsstandards vereinbart zu haben.

Zum Beispiel verwende ich lowerCamelCase für Instanzen, Variablen und UpperCamelCase für Klassen usw.

Codierungsstandards sollten dieses Problem beheben.

Wenn ich erfolgreiche Open-Source-Programme betrachte, haben sie oft Codierungsstandards

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Das Einverständnis mit den Kodierungsstandards sollte der letzte Kampf sein, den Sie darüber haben.

Schauen Sie sich den Wikipedia-Eintrag an (von http://en.wikipedia.org/wiki/CamelCase ).

Programmier- und Codierungsstil

Manchmal wird eine interne Großschreibung empfohlen, um Wortgrenzen durch die Codierungsstilrichtlinien zum Schreiben von Quellcode anzugeben (z. B. die Programmiersprache Mesa und die Programmiersprache Java). Die in einigen dieser Richtlinien enthaltenen Empfehlungen werden von statischen Analysetools unterstützt, die den Quellcode auf Einhaltung prüfen.

Diese Empfehlungen unterscheiden häufig zwischen UpperCamelCase und LowerCamelCase und geben in der Regel an, welche Sorte für bestimmte Arten von Entitäten verwendet werden soll: Variablen, Datensatzfelder, Methoden, Verfahren, Typen usw.

Ein weit verbreiteter Java-Codierungsstil schreibt vor, dass UpperCamelCase für Klassen und LowerCamelCase für Instanzen und Methoden verwendet werden. [19] Einige IDEs wie Eclipse erkennen diese Verwendung und implementieren Verknüpfungen, die auf CamelCase basieren. Wenn Sie beispielsweise in der Inhaltsunterstützungsfunktion von Eclipse nur die Großbuchstaben eines CamelCase-Wortes eingeben, wird ein passender Klassen- oder Methodenname vorgeschlagen (wenn Sie beispielsweise "NPE" eingeben und die Inhaltsunterstützung aktivieren, wird möglicherweise "NullPointerException" vorgeschlagen).

Die ursprüngliche ungarische Notation für die Programmierung gibt an, dass eine Abkürzung in Kleinbuchstaben für den "Verwendungstyp" (kein Datentyp) allen Variablennamen vorangestellt werden soll, der Rest des Namens in UpperCamelCase. als solches ist es eine Form von lowerCamelCase. CamelCase ist die offizielle Konvention für Dateinamen in Java und für den Amiga-PC.

Microsoft .NET empfiehlt lowerCamelCase für Parameter und nicht öffentliche Felder und UpperCamelCase (auch bekannt als "Pascal Style") für andere Arten von Bezeichnern. [20]

Python empfiehlt UpperCamelCase für Klassennamen. [21]

Die NIEM-Registrierung erfordert, dass XML-Datenelemente UpperCamelCase verwenden und XML-Attribute lowerCamelCase verwenden.

Es gibt keine einheitliche Konvention für die Aufnahme von Abkürzungen in Großbuchstaben (hauptsächlich Akronyme und Initialismen) in CamelCase-Namen. Ansätze umfassen das Belassen der gesamten Abkürzung in Großbuchstaben (wie in "useHTTPConnection") und das Belassen nur des ersten Buchstabens in Großbuchstaben (wie in "useHttpConnection").

Kamel Fall ist in der Datenverarbeitung keineswegs universell. Benutzer mehrerer moderner Programmiersprachen, insbesondere der Familien Lisp und Forth, verwenden fast immer Bindestriche. Zu den manchmal angeführten Gründen gehört, dass dies bei den meisten Tastaturen kein Verschieben erfordert, dass die Wörter besser lesbar sind, wenn sie getrennt werden, und dass die Kamelhülle in Sprachen, in denen die Groß- und Kleinschreibung nicht berücksichtigt wird (z Common Lisp, das zwar technisch gesehen zwischen Groß- und Kleinschreibung unterscheidet, aber Bezeichner standardmäßig in Großbuchstaben kanonisiert (faltet)).

Stewart Robinson
quelle
2

Es ist möglich, stärker zu argumentieren, dass Methodennamen dieser Art nicht nur harmlos sind, sondern auch ein Indikator für Code guter Qualität sein können.

  • Ein Indikator für eine gute Code-Granularität: Wenn Ihre Methoden kurz, zweckgebunden und beschreibend benannt sind, benötigen Sie nicht viele Informationen in Variablennamen. Wenn Sie lange Methoden haben, die viele Dinge tun und viel Kontext und Status im Auge behalten müssen, müssen Ihre Variablennamen aussagekräftiger sein.

  • Ein Indikator dafür, dass Allzweckberechnungen in Allzweckmethoden verschoben werden: Wenn Sie eine Zwischenmanipulation von Datenstrukturen in einer Geschäftsmethode durchführen, z. B. ein Array von Benutzern dedupliziert werden muss, müssen Variablen im Gültigkeitsbereich vorhanden sein mit Namen wie users[]und deduplicatedUsers[]. Wenn Sie die Deduplizierung in eine Dienstprogrammmethode verschieben, können Sie die Methode Utils.dedup(array)aufrufen und das deduplizierte Array deduplicatedArrayoder einfach aufrufen result.

  • Java-Dekompilierer verwenden häufig ein solches Schema zum Benennen lokaler Variablen (Instanz- und Klassenvariablen sind normalerweise im Bytecode verfügbar, lokale Variablen jedoch nicht), und die Ergebnisse sind besser lesbar als erwartet, tatsächlich oft besser lesbar als die Originalquelle.

  • Siehe Larry Walls Prinzip "Lokale Mehrdeutigkeit ist in Ordnung" - http://www.wall.org/~larry/natural.html .

user8599
quelle
2

Ich würde sagen, dass Sie wahrscheinlich eine bestimmte Verwendung im Auge haben, wenn Sie ein Objekt erstellen. Der Typ allein spiegelt diese Verwendung sehr selten wider.

Wenn Sie also einen neuen Kontakt in Ihrer Adressbuchanwendung erstellen möchten, möchten Sie möglicherweise die Variable aufrufen newContact.

Wenn Sie Ihren Code als Einheit testen, um das Verhalten von PersonObjekten ohne festgelegte Namen zu überprüfen , möchten Sie sie möglicherweise aufrufen unnamedPersonoder ähnliches.

Wenn Sie es einfach personaufrufen, haben Sie keine große Chance, Ihren Code selbst zu dokumentieren.

Joachim Sauer
quelle
Nenne es anonym! :)) var anonym = neue Person (); Oder noch besser: var you_know_who = new Person (); :))
Vadim Ferderer
@Vadim Ferderer : var he_who_must_not_be_named = new Person();? :-)
Platinum Azure
2

Nur wenn Sie in VB6 programmieren. In diesem Fall ist das, was Sie tun, illegal, aber nicht unmoralisch.

Brianegge
quelle
1

Ich mache es auch und verstehe auch nicht, warum es "unmoralisch" sein sollte. Ich kann zwar verstehen, dass es manchmal verwirrend sein kann, aber heute haben wir IDEs mit Intellisense- und Syntaxhervorhebung, die sicherstellen, dass Sie (wenn Sie einen Fehler machen und Ihre Variable anstelle Ihrer Klasse referenzieren und umgekehrt) dies tun sehen Sie Ihren Fehler ziemlich schnell. Und wir haben auch den Compiler. :) :)

Frederik Gheysels
quelle
1

Ich sehe auch kein Problem mit dieser Praxis. Solange es nur eine Variable dieser Klasse gibt, ist es einfach zu schreiben und leicht zu lesen. Imo, das gilt sogar in einem einfachen Texteditor. Ich persönlich kann mich an niemanden erinnern, der dies als schlecht oder sogar unmoralisch bezeichnet. Mach einfach weiter :)

Mafu
quelle
1

Ich denke, die 'Regel', an die Sie vielleicht denken, ist eher für primitive Typen und Klassen gedacht, bei denen der Klassenname einen schlechten Variablennamen ergibt.

Wenn Sie beispielsweise die Kosten eines bestimmten Artikels in einem Online-Shop berechnen möchten, ist der folgende Code keine gute Form:

Decimal _decimal = item.BaseCost + item.Tax;

Stattdessen wird ein aussagekräftigerer Name empfohlen, z. B. "_total" oder "_cost".

Jay S.
quelle
1

Das einzige Problem mit solchen Dingen, das ich gefunden habe, ist, wenn Sie den gleichen Namen für ein privates Mitglied und auch für ein öffentliches Eigentum wünschen.

Wenn sich diese nur für den Fall unterscheiden, funktioniert dies in Sprachen mit Groß- und Kleinschreibung wie C #, jedoch nicht in VB.NET.

So würde ich zum Beispiel in VB schreiben

Private _name As String

aber

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Ich würde dasselbe in C # tun, so dass die Übersetzung von einem zum anderen schmerzlos ist. Es macht es auch ein bisschen weniger fehleranfällig, da es sehr leicht ist, Wörter falsch zu lesen oder falsch zu schreiben, die sich nur von Fall zu Fall unterscheiden.

ChrisA
quelle
Das einzige, was ich an diesem Ansatz nicht mag, ist, dass Variablen, denen ein einzelner Unterstrich vorangestellt ist, in der Regel mit privaten Mitgliedern einer Klasse verknüpft sind. Aber ich nehme an, dass der allgemeine Ansatz anständig ist.
Jason Baker
Ja, das ist es, was ich hier illustriere. Das Definieren einer lokalen Variablen wie "Person als neue Person dimmen" wäre in Ordnung. Sehr (sehr) gelegentlich gibt es beim VB-Compiler eine Mehrdeutigkeit, und die normale beruhigende automatische Großschreibung findet nicht statt. Es ist ein guter visueller Hinweis, dass nicht alles in Ordnung ist.
ChrisA
1

Nicht unmoralisch, aber wenn Ihr bester Name für Ihre Variable der Name des Typs ist, stimmt etwas nicht oder Sie machen nur einen Proof of Concept oder ähnliches. Für mich muss sich ein Variablenname auf die Bedeutung im Geschäftskontext beziehen und nicht auf die Programmiersprache. Es wird schwieriger sein, den Code zu verstehen.

João Cintra
quelle
1

Ich benutze Person person = new Person()mich oft . Wird häufig in Java / C # verwendet.

Obwohl ich mich gestern gefragt habe, warum

private enum DataType {NEW, OLD}

funktioniert nicht in C # ...

Vor allem zu sehen , wie Sie verwenden können String, string, Double, double, ... nach Belieben in C #.

Carra
quelle
enum unterstützt nur byte, sbyte, short, ushort, int, uint, long, ulong. dh nicht gebrochene numerische Werttypen
Kev
1
Person person = new Person()

ist gut in meinem Buch.

Wheh es schrecklich wird, wenn Sie haben:

string Person;
string person;

Sehr einfach, die 2 zu verwechseln.

Johnno Nolan
quelle
1

Was mir gesagt wurde, außer dass wir unsere Codierungsstandards nicht erfüllen, ist, Verwirrung zu vermeiden, wenn jemand anderes meinen Code liest. Ich persönlich sehe kein Problem damit, solange die Bedeutung klar ist.

Bei CLR-Typen (int, string usw.) können Sie entweder String oder string (usw.) verwenden, um den Typ zu deklarieren. Daher würde ich die Verwendung von so etwas vermeiden

int Int = 0;
string String = "hi there";
Muad'Dib
quelle
1

Es ist gefährlich, die Großschreibung zum einzigen Unterschied zu machen. Machen Sie dies für ein großes Projekt weiter, und ich garantiere Ihnen, dass Sie auf bizarre Fehler stoßen, die Sie scheinbar nicht finden können.

fastPerson / slowPerson wie oben sind in Ordnung ... sie sind beschreibend und unterscheiden sich vom Variablentypnamen ... aber Mann, ein int "Int" zu nennen wäre einfach faul.

Alexwood
quelle
1

Ich würde sagen, es ist niemals unmoralisch - es ist wirklich nur der Name Ihrer Basislinienvariablen. Wenn Sie sich keinen besseren Namen vorstellen können, ist es eine gute Standardeinstellung, ihn nach seinem Typ zu benennen. ( Nur für komplexe Typen - für eingebaute Typen ist es böse. ) Und viel Zeit gibt es wirklich keinen besseren Namen, weil Sie ihn nicht verwenden. Ich weiß nichts anderes über die Variable. Wie bei dieser Methode

void SaveToDatabase(Person person) {...}

Das einzige, was Sie vernünftigerweise als Person bezeichnen könnten, ist person_to_saveoder so etwas, das überflüssig erscheint.

In vielen Fällen können Sie jedoch die Lesbarkeit Ihres Codes verbessern, indem Sie die Person durch einen aussagekräftigeren Namen ersetzen. Zum Beispiel ist dies weniger beschreibend

void AddToAccount(Account account, Person person)  {...}

als das

void AddToAccount(Account account, Person dependent)  {...}

Bitte, bitte - bitte, bitte setzen Sie kein 'a' oder 't' vor den Typnamen. IE aPerson für 'eine Person' oder tPerson für 'die Person'. Es ist zu kompliziert und bringt nicht viel, wenn überhaupt einen Wert. Außerdem verschmutzen Sie Ihren Bereich mit einer Reihe von Variablen, die mit a oder t beginnen und den Wert von Intelli-Sense minimieren können.

Joshua
quelle
Ich stimme dem letzten Absatz zu. Ich sehe keinen Grund, fremde Zeichen hinzuzufügen, nur um ein kleines Stilproblem zu vermeiden.
Jason Baker
0

Ich würde nicht sagen, dass es schrecklich ist. Normalerweise stelle ich dem Namen der Variablen in dieser Art von 'ein' voran, um zu zeigen, dass es sich um eine einzelne Instanz des Typs handelt, also würde ich es tun

Person aPerson = new Person();

Es macht den Code natürlicher zu lesen, denke ich.

Rob K.
quelle
0

Es ist absolut nichts Falsches daran, vorbehaltlich der von anderen hervorgehobenen Einschränkungen (hier der Einfachheit halber zusammengefasst): Nicht mit primitiven Typen, Umgestaltung der ursprünglichen Instanz, wenn später eine andere Instanz hinzugefügt wird, ohne Verwendung von Groß- und Kleinschreibung zur Unterscheidung von Klassennamen usw.

Meine Faustregel? Anweisungen im Code sollten wie einfache englische Sätze gelesen werden.

Person Person = neue Person ();

Mitarbeiter Mitarbeiter = person.getRole (MITARBEITER);

Parent parent = person.getRole (PARENT);

person.getFullName ();

employee.getSalary ();

parent.getChildren ();

parent.getFullName (); // unter der Annahme, dass das Dekorationsmuster im Spiel ist

if (person.hasRole (MITARBEITER)) {

  ...

}}

Und so weiter.

Wenn der Gültigkeitsbereich der Variablen begrenzt ist (die Kapselungsmethode umfasst beispielsweise 10-15 Zeilen), kann ich sogar 'p' anstelle von 'person' verwenden. Kürzere Variablennamen lenken weniger ab, wenn Sie versuchen, den Kontext im Kopf zu behalten. Vermeiden Sie unbegründete Präfixe wie "a" oder (schaudernde) ungarische Notation und deren Ableger. (Wohlgemerkt, ich habe nichts gegen solche Präfixe, wenn sie im entsprechenden Kontext verwendet werden - C ++ / COM / ATL / Win32-API-Code usw., wo es hilft, Zuweisungen / Typumwandlung gerade zu halten).

Meine zwei (!) Bits :-)

alan-p
quelle