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

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.

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

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.

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

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

var abc = new Person();

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.

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.

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.

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.

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.

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.

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.

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.

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.

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()

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)).

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 .

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.

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

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. :) :)

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 :)

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".

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.

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.

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 #.

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.

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";

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.

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.

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.

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 :-)