Was ist der Grund für die Verwendung von Kleinbuchstaben für das erste Wort in einer lokalen Variablen (z. B. employeeCount, firstName)?

Ich lasse mich von anderen Programmierern kritisieren, da ich für alle meine Variablen die korrekte Schreibweise verwende. Beispielsweise wird ein typischer Programmierer employeeCounteinen Variablennamen verwenden, den ich jedoch verwende EmployeeCount. Ich verwende für alles die richtige Groß- und Kleinschreibung , sei es eine leere Methode, eine Rückgabemethode, eine Variable, eine Eigenschaft oder eine Konstante. Ich folge dieser Konvention sogar in Javascript. Das letzte rauscht wirklich die Leute jimmies.

Der typische Grund, warum ich diese "Nicht-Standard" -Gehäusekonvention nicht befolgen sollte, ist, dass die vollständige korrekte Schreibweise für Eigenschaften und nichtige Methoden reserviert werden sollte. Lokale Variablen und Methoden, die einen Wert zurückgeben, sollten das erste Wort in Kleinbuchstaben haben int employeeCount = getEmployeeCount().

Ich verstehe jedoch nicht warum.

Wenn ich das in Frage stelle, bekomme ich anscheinend nur eine willkürliche Antwort , die dem Standard entspricht . Was auch immer die Antwort ist, es läuft normalerweise immer darauf hinaus, dass es so ist und ich es nicht in Frage stelle. Ich folge ihm einfach. . Willkürliche Antworten sind mir nie gut genug.

Seitdem ich Excel 97-Makros mit der Office-IDE programmiert habe, habe ich nie mehr eine Groß- / Kleinschreibung benötigt, um festzustellen, ob es sich um eine lokale Variable oder eine Eigenschaft handelt. Das liegt daran, dass ich immer eine sehr intuitive Namenskonvention verwendet habe. Schlägt zum Beispiel GetNuggetCount()eindeutig eine Methode vor, die irgendwohin geht und eine Zählung aller Nuggets abruft. SetNuggetCount(x)schlägt vor, dass Sie der Anzahl der Nuggets einen neuen Wert zuweisen. NuggetCountAlleine deutet dies auf eine Eigenschaft oder lokale Variable hin, die einfach einen Wert enthält. Zu letzterem mag man versucht sein zu sagen: "Ah ha! Das ist die Frage. Eigenschaft oder Variable? WAS IST ES?" Darauf antworte ich mit: "Ist das wirklich wichtig?"

Also, hier ist der Text: Was sind die objektiven, logischen und nicht willkürlichen Gründe, Kleinbuchstaben für das erste Wort in Ihrer Variablen- oder Rückgabemethode zu verwenden?

Edit: Für MainMa

Ersetzen Sie diesen Code durch das erste Codebeispiel in Ihrer Antwort und sehen Sie, wie gut Ihre Argumentation funktioniert:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Diese Namenskonvention wird häufig verwendet, wenn Benutzer einer Variablen denselben Namen wie ihrem Typ geben möchten. Beispielsweise:

Employee employee;

Einige Sprachen erzwingen diese Großschreibung sogar. Dadurch wird verhindert , wie lästige Variablennamen verwenden MyEmployee, CurrentEmployee, EmployeeVarusw. Man kann immer sagen , wenn etwas eine Art oder eine Variable ist, nur aus der Aktivierung. Das verhindert Verwirrung in Situationen wie:

employee.function(); // instance method
Employee.function(); // static method

Außerdem werden Substantive im Englischen im Allgemeinen nicht großgeschrieben, sodass Sie nicht wirklich behaupten können, dass die Großschreibung "richtig" ist.

Was hat das mit Ihrer Situation zu tun? Sie haben offensichtlich keine Probleme, Ihren eigenen Code zu lesen, aber indem Sie die Dinge so konsistent wie möglich halten, verringern Sie die mentale Arbeitsbelastung aller anderen, die Ihren Code lesen müssen. Beim Codieren wie beim Schreiben passen Sie Ihren Stil an die Leser an.

Es gibt keine. Es ist das, was die meisten Menschen tun, und deshalb ist es zum Standard geworden, weil das jeder tut. Eine Menge Literatur folgt dieser Konvention, so dass die Leute die Gewohnheit aufgreifen.

Die Konvention ist nicht so wichtig wie die Konsistenz im gesamten Code. Solange alles einheitlich benannt ist, damit ich erkennen kann, welche Dinge auf sie gerichtet sind, spielt es keine Rolle, ob der erste Buchstabe in Großbuchstaben geschrieben ist oder nicht.

Ich würde es komisch finden, auf Code zu stoßen, der auf Ihre Weise geschrieben wurde, und würde sagen, dass es mir nicht gefällt. Aber das ist eine Frage des Stils.

Wenn Sie dies jetzt am Arbeitsplatz tun, ist es besser, im Stil des Teams zu codieren, damit der Code überall konsistent bleibt. Anstatt dass Ihr Code anders ist als jeder andere.

http://thecodelesscode.com/case/94

1. Warum gibt es den Standard?

Wäre es nicht besser, wenn jeder den Code nach persönlichen Wünschen schreibt und nicht mehr darüber spricht, welcher Standard besser ist?

Tatsache ist, dass es schwieriger ist, Code zu lesen, der einen anderen Stil verwendet, wenn Sie sich an einen bestimmten Stil gewöhnt haben. Ihr Gehirn verbringt mehr Zeit damit, die Konvention zu verstehen (falls vorhanden), anstatt zu verstehen, was der Code tut.

Was ist zwischen diesen beiden Codeteilen besser lesbar?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

oder:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Beide Codeteile werden auf ähnliche Weise ausgeführt. Der einzige Unterschied besteht darin, dass im ersten Fall jeder Entwickler, der an dem Projekt gearbeitet hat, seinen eigenen Stil verwendet hat. Dies machte den Code inkonsistent, unlesbar und gefährlich. Die Tatsache , dass die Mitglieder des Teams nicht in der Lage waren , über die Einrückungsgröße zu vereinbaren, mit der Tatsache, dass einer von ihnen weigert geschweiften Klammern zu verwenden , nachdem jeder ifdes Code extrem fehleranfällig gemacht: Blick auf sie, können wir glauben , dass der zweite ifist wird nur ausgeführt, wenn die erste ifwahr ist, was nicht der Fall ist.

Im zweiten Fall folgten alle Entwickler dem gleichen Standard. Einige von ihnen waren vielleicht unglücklich, weil sie Einrückungen mit zwei Leerzeichen bevorzugten oder weil sie an Methoden gewöhnt waren, die mit einem kleinen Buchstaben beginnen. Tatsache ist, dass der Code auf diese Weise immer noch viel besser lesbar ist und es auch immer noch wäre, wenn sie einen anderen Standard verwenden würden.

Durch einen strengen, einheitlichen Standard wird das Lesen des Codes erleichtert.

2. Warum ist ihr Standard besser als der, den ich gerade erfunden habe?

Wenn ein Standard von Hunderttausenden von Entwicklern auf der ganzen Welt verwendet wird, bleiben Sie einfach dabei. Erfinden Sie nicht Ihre eigenen: Auch wenn es besser ist, ist es für Sie einfacher, auf den globalen Standard zu migrieren, als für die Hunderttausenden von Entwicklern, die Ihre verwenden möchten.

Beispiel: In meiner eigenen Firma habe ich eine spezielle Konvention zum Benennen von Primär- und Fremdschlüsseln und Indizes in der Datenbank. Diese Namen sehen aus wie:

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] oder
• [PK for RoleOfPassword: RoleId, PasswordId].

Persönlich finde ich diese Konvention hervorragend und äußerst klar. Für mich. Aber es ist total beschissen. Es ist scheiße, weil es meins ist und weil niemand von Tausenden von Datenbankadministratoren es nie benutzt hat. Das bedeutet, dass:

• Wenn ich einen DBA anheuere, wird er gezwungen sein, die neue Konvention zu lernen, anstatt jetzt mit seiner Arbeit zu beginnen.

• Ich kann keine Code-Teile im Internet teilen, wie sie sind: Diese seltsam aussehenden Namen stören Leute, die meinen Code lesen,

• Wenn ich Code von außen nehme, um ihn selbst zu verwenden, wäre ich gezwungen, die Namen zu ändern, um ihn zu vereinheitlichen.

• Wenn ich mich eines Tages für einen bekannten Standard entscheide, werde ich gezwungen sein, alle paar hundert Namen zu ändern.

3. Wie steht es also mit der Großschreibung?

Eigenschaften haben einen größeren Bereich oder eine größere Sichtbarkeit als Felder oder lokale Variablen. Eigenschaften beginnen mit einem Großbuchstaben und Felder und Variablen - mit einem kleinen geht man in diese Richtung.

Wenn Sie C # in Betracht ziehen, ist diese Logik konsistent genug.

Wenn Sie Java in Betracht ziehen, beginnen Methoden mit kleinen Buchstaben, was der Logik nicht folgt.

Nein, es gibt keinen endgültigen Beweis dafür, dass diese Konvention besser ist als Ihre. Es ist nur so, dass der eine global verwendet wird und der andere nicht. Keiner ist besser .

In JavaScript beginnen Funktionen mit einem kleinen Buchstaben, es sei denn, sie erfordern einen vorangestellten Buchstaben new. Wäre es nicht besser umgekehrt? Vielleicht. Tatsache ist, dass JavaScript-Entwickler jahrelang diesen Standard verwendeten und nicht das Gegenteil. Jedes Buch neu zu schreiben und jeden Entwickler zu zwingen, den Stil jetzt zu ändern, wäre etwas kompliziert.

Technisch spielt es keine Rolle (oder zumindest in den meisten Sprachen nicht).

Die meisten Programmiergemeinschaften (ob es sich nun um weltweite Gemeinschaften handelt, die sich um eine bestimmte Sprache gebildet haben, Untergruppen solcher Gemeinschaften, Gruppen, die sich um eine populäre Bibliothek oder ein Toolkit gebildet haben, oder nur einzelne Teams) haben etablierte Codierungsstandards entwickelt. Die genauen Details sind relativ unwichtig (wenn auch in vielen Fällen kann ein gutes Argument für sie gemacht werden), was ist wichtig, dass Sie bei ihnen bleiben.

Nicht weil sie die besten sind, sondern weil sie das sind, was alle anderen nutzen. Wenn Sie sich an den Standard halten, stimmt Ihr Code mit den meisten anderen Codes überein, die Sie möglicherweise verwenden werden - Bibliotheken, Teamkollegen-Code, integrierte Sprachen. Konsistentes Benennen ist eine leistungsstarke Produktivitätswaffe, da dies bedeutet, dass Sie normalerweise richtig raten, wenn Sie den Namen von etwas erraten. Ist es file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Die Namenskonvention sagt es Ihnen.

Das Übertragen Ihrer persönlichen Vorlieben in jede Sprache, der Sie begegnen, ist besonders gefährlich, da zuallererst jede Sprache ihre eigene Kultur hat und die Namenskonventionen oft nicht kompatibel sind. und zweitens gibt es in Bezug auf die Benennung viele subtile Unterschiede zwischen den Sprachen.

Nur ein Beispiel: In C # leben Typen und Variablen in separaten Namespaces. Der Compiler ist schlau genug, um den Unterschied zu erkennen. In C teilen sich jedoch beide Arten von Namen einen Namespace, sodass Sie keinen Typ und keine Variable mit demselben Namen innerhalb desselben Bereichs haben können. Aus diesem Grund benötigt C eine Namenskonvention, die Typen von Variablen unterscheidet, während C # dies nicht tut.

Ich bin überrascht, dass niemand anderes dies gesagt hat, aber ich denke, der Unterschied in der Groß- und Kleinschreibung ist aus einem Grund erstaunlich hilfreich: Es ist schön und bequem zu wissen, ob eine Variable nur einen lokalen Bereich hat oder nicht. Wenn die Variable lokal ist, kümmere ich mich nicht so sehr um die Nebenwirkungen einer Änderung, wie z. B. das Umgestalten des Namens. Ich mag also eine Konvention, die Klassenmitglieder von privaten Klassenvariablen und lokalen Variablen unterscheidet.

Mit modernem Intellisense spielt dies immer weniger eine Rolle, aber es gibt mir immer noch einige Orientierungspunkte, wenn ich Code lese, um zu wissen, wo ich nach der Definition suchen soll.

Und ein gutes Stück davon könnte von meinem schlechten Stil vor Jahren übrig geblieben sein, als es unwahrscheinlich war, dass Methoden auf einen Bildschirm passten.

Dies scheint eher eine Frage der Konventionen zu sein als Ihrer spezifischen Konvention.

Für jede Konvention, die Sie brechen, fügen Sie einfach mehr Arbeit für alle anderen hinzu. In einer perfekten Welt arbeitet das gesamte Unternehmen vielleicht sein ganzes Leben lang an einem einzigen Produkt. In Wirklichkeit ist dies jedoch nicht der Fall. Die Leute springen zwischen Projekten, manchmal unternehmensweit oder sogar zum Spaß. Je zufälliger der Code ist, desto schwieriger und teurer ist die Bearbeitung. Als Unternehmer oder Stakeholder möchte ich keine Entwickler einstellen, die eher egoistisch als zum Wohle des Projekts denken.

Das läuft auf Professionalität hinaus: Manchmal müssen wir unseren persönlichen Stil beiseite legen und das wählen, was für die Massenadoption effizienter ist. Dies fördert die Zusammenarbeit und beseitigt fremde Hindernisse, die eigentlich gar nicht vorhanden sein sollten.

Wie für Ihre eigentliche Konvention ist CapitalCamelCase normalerweise für Klassennamen (oder in Javascript, Konstruktoren) reserviert. Wenn ich eine großgeschriebene Variable sehe, wird eine fundierte Vermutung diktieren, dass ich sie instanziieren muss, um sie zu verwenden. Wenn das falsch ist, werde ich sauer sein, dass der Code nicht den Community-Standards entspricht. Selbst bei den meisten anderen Sprachen wird jeder, der es zum ersten Mal betrachtet, sofort in die Irre geführt. Ich möchte, dass der Code offensichtlich und nicht irreführend ist.

"Weil die vollständige Groß- und Kleinschreibung für Eigenschaften und leere Methoden reserviert sein sollte. Lokale Variablen und Methoden, die einen Wert zurückgeben, sollten das erste Wort in Kleinbuchstaben haben", da dies eine Standardkonvention ist.

Andere Programmierer rufen gerade Ihren Code auf und denken, dass dies eine Eigenschaft und eine lokale Variable ist, was Ihre Arbeit erschwert.

Wie andere gesagt haben, gibt es keinen wirklichen Grund, außer eine Namenskonvention zu verabschieden. Wenn Sie Ihr gesamtes Team auf die gleiche Seite bringen können, können Sie sich möglicherweise Zeit sparen. Zum Beispiel habe ich persönlich eine Codierungsstandard-Sache gestartet, die in diese Sache eingeflossen ist, und wir haben camelCase für alle privaten Varianten sowie für von Val übergebene Dinge verwendet, wohingegen wir PascalCase für Dinge verwendeten, die öffentlich sind sowie für Dinge, die von Ref.

Linien werden ein wenig verschwommen, wenn es um Dinge wie geschützt oder aus oder so geht.

Sprache (mit ihrem formalen und konventionellen Aspekt) ist wichtig für die Organisation Ihrer Gedanken, sie hat Macht über Ihre Denkweisen. Es ist also nur ein Schmerz, von einem Stil zum anderen zu wechseln.

Symbole in Klein- und Großbuchstaben weisen große semantische Unterschiede in Haskell auf. Sie unterscheiden sich auch geringfügig in Scala, und ich habe beide verwendet. Andere Sprachen, die ich verwende, machen keinen Unterschied zwischen diesen beiden Arten von Bezeichnern, aber ich halte meine Gedanken in der Art und Weise, wie Haskell Bezeichner wahrnimmt, für viel einfacher, als meinen Geist für verschiedene Sprachen zu fragmentieren.

Für mich kommt es auf die Erwartung an.

Wenn ich den meisten Code lese, erwarte ich, dass alles, was mit a beginnt lowerCase, eine lokale Variable oder eine Funktion ist (in C # wäre das nur eine Variable). Wenn ich eine lokale Variable in ProperCasesehe, würde ich wahrscheinlich stolpern und für eine Weile verwirrt sein und denken, dass es entweder ein Klassenname oder eine Eigenschaft oder etwas anderes ist. Das würde mich veranlassen, den Code erneut zu lesen und mich zu ärgern.

Das ist wahrscheinlich, was in Ihrem Fall passiert.

Darüber hinaus ist es praktisch, anhand des ersten Buchstabens zu erkennen, welche Rolle eine Variable spielt, und Kollisionen zwischen einem Instanznamen und einem Klassennamen zu vermeiden.

Für lokale Variablen sollte zur Erleichterung der Eingabe Kleinbuchstaben verwendet werden (Geschwindigkeit / keine Umschalttaste). Großbuchstaben werden verwendet, um die Lesbarkeit zu verbessern, indem die Wörter in einem Namen getrennt werden. Code mit lokalen Variablennamen aus einem Wort (die gebräuchlich sein sollten) ist schnell und einfach einzugeben. Die Verwendung von Großbuchstaben für jedes neue Wort im Namen ist auch schneller (und mit weniger Leerzeichen) als die Verwendung von Unterstrichen, die ein weiteres Zeichen hinzufügen - dies wird auch als Kamelbuchstabe bezeichnet.

Ich stimme dem OP hier zu. camelCase sieht einfach falsch aus. Ich stimme auch der Tatsache zu, dass dies der Standard ist und wir uns an denselben Standard halten müssen, oder was der Sinn ist, einen Standard zu haben. Es ist auch sinnvoll, PascalCaps für Methoden usw. und camelCase für Ihre eigenen Variablen usw. zu verwenden, um zu unterscheiden, wenn Sie keine IDE verwenden, die Methoden für Sie einfärbt.

Um das zu umgehen, setze ich den Namen meines Objekts immer den Objekttyp voran. Wenn es sich also um eine String-Variable handelt, rufe ich strMyVariable auf. Wenn es sich um eine Art Objekt handelt, nenne ich es objMyObject usw. Auf diese Weise beginnt es mit Kapitälchen gemäß dem Standard und es sieht richtig aus.