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

20

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);
    }
}
oscilatingcretin
quelle
7
Wenn sie in Großbuchstaben geschrieben wären, würde sich jemand anderes fragen, warum sie nicht in Kleinbuchstaben geschrieben
wären
11
Wäre es nicht schön, wenn unsere leistungsstarken IDEs ein Plugin hätten, das unsere persönlichen Vorlieben für Stilfragen wie diese abbildet und uns erlaubt, sie zu verwenden, aber hinter den Kulissen, für die "echte Version" der Quelldatei, angewendet die Stilsemantik des Projekts. Dies ist eine rein visuelle Angelegenheit, bis Sie die offizielle Dateiversion prüfen müssen. nur träumen ...
Sassafras_wot
59
Leider für Sie ist der tatsächliche und gültige Grund "weil es der Standard ist". Es zahlt sich aus, wenn Personen im selben Team denselben Codestilstandard befolgen. Wenn Sie nicht verstehen, warum, dann sollten Sie vielleicht eine andere Frage stellen: "Warum sind Standards nützlich?"
Andres F.
3
Ich bin immer davon ausgegangen, dass sich Entwickler für camelCase entschieden haben, weil es so aussah. Es gibt keinen objektiven Grund für camelCase selbst über PascalCase. Ich persönlich finde PascalCase (wie Ihr Beispiel) viel einfacher zu lesen und benutze es an den meisten Stellen außer JavaScript, wo ich bei camelCase bleibe, damit ich keine Partyeinladungen verpasse.
GrandmasterB
7
Untersuchung der Vorteile eines Standard-Codierungsstils Es spielt keine Rolle, was der Standard ist, nur, dass er befolgt wird.
Mr.Mindor

Antworten:

88

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.

Karl Bielefeldt
quelle
1
Beachten Sie, dass das Problem in der vom OP verwendeten Sprache weiterhin besteht, da die Eigenschaften in Großbuchstaben geschrieben sind (natürlich kann den Eigenschaften das Präfix vorangestellt werden this., wodurch die Verwechslung vermieden wird; lokale Variablen können kein solches Präfix haben).
Arseni Mourzenko
1
@oscilatingcretin heißt es PascalCase.
Mr.Mindor
21
Employee Employeefunktioniert, aber ich werde argumentieren, dass es für einen menschlichen Leser verwirrender ist als Employee employee. Letzteres sieht aus wie zwei verschiedene Dinge. Die erste sieht nach unnötiger Wiederholung aus.
Jamie F
14
@oscilatingcretin Genau: "setzt voraus, dass der Leser das zugrunde liegende Framework versteht ..." Ich lese gerne JavaScript, Java, C #, C ++ und andere und übersetze den Code in meinem Kopf. Ich mag es nicht, ständig darüber nachzudenken, "Oh, der Compiler dieser Sprache kann mit x umgehen ." während ich nur versuche, die Bedeutung des Codes zu verstehen.
Jamie F
1
Beachten Sie, dass employee.function()dies auch eine statische Methode sein kann, wenn die Sprache das Aufrufen statischer Methoden von einem Objekt aus zulässt (wie dies bei Java der Fall ist). Der Compiler gibt eine Warnung aus, aber das ist erlaubt.
Uooo
34

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

Schleis
quelle
3
Ich wünschte, die meisten Programmierer wären wie Sie. Viele sind fragwürdig leidenschaftlich und / oder dogmatisch, wenn es darum geht, den von mir erwähnten Gehäusestandard einzuhalten.
oscilatingcretin
1
@Schieis ist es wichtig, ob Sie der nächste Programmierer sind, der an dem Projekt arbeitet.
N4TKD
3
@oscilatingcretin Wenn Sie an Code gearbeitet haben, der voll von Code ist, werden Sie möglicherweise leidenschaftlich und / oder dogmatisch var m_someVariableID = GetVariableValueId(). Vor allem , wenn Sie es zu tun haben, ohne die automatische Vervollständigung Unterstützung.
Tacroy
7
Wenn Sie in einem Team sind, ist es wichtig, dass Sie den Teamstandards folgen. Beachten Sie jedoch, dass viele Programmiersprachen De-facto-Standards haben, denen Sie folgen sollten, wenn Sie ein neues Projekt erstellen, für das das Team keine Standards hat (oder für das das Team die Festlegung auf Sie verschoben hat). Wenn Sie sich nicht sicher sind, welche Codierungskonvention Sie verwenden sollen, ziehen Sie die Konvention des Anbieters der Primärsprache oder des enthaltenen Frameworks Ihrem eigenen Standard vor, es sei denn, Sie können Ihren Standard rechtfertigen.
Brian
2
@Schleis gutes Update, ich bin nicht einverstanden, dass es nur eine Frage des Stils ist, aber Konventionen und Konventionen werden aus guten Gründen zu Konventionen und sollten befolgt werden. Es ist keine Religion und manchmal muss man sehr von Konventionen abweichen, aber man sollte einen guten Grund haben.
N4TKD
25

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.

Arseni Mourzenko
quelle
1
Was den Teil betrifft, in dem Code weniger lesbar ist, weil er einem etwas anderen Standard folgt, hatte ich dieses Problem noch nie. Sofern die Variablen eines anderen nicht so benannt sind hookyDookyDoo, beeinträchtigt keine Benennung oder Groß- / Kleinschreibung die Lesbarkeit. Denken Sie auch daran, dass ich nicht sage, dass meine Konvention "besser" ist, da sie nichts Besonderes auf den Entwicklertisch bringt. Schließlich verstehe ich Ihren Standpunkt nicht, dass [Eigenschaften einen größeren Umfang haben ... in diese Richtung gehen] . Was hat der Geltungsbereich mit der Gehäusekonvention zu tun? In welche Richtung gehen?
oscilatingcretin
23
@oscilatingcretin, die Frage ist nicht, ob Sie jemals dieses Problem hatten, es ist, ob Ihre Kollegen haben. Offensichtlich haben sie oder sie würden sich nicht beschweren.
Karl Bielefeldt
1
Betreff: Ihre Bearbeitung: Ihr erstes Codebeispiel zeigt einfach schlecht konstruierten, für Katastrophen anfälligen Code. In meinem OP geht es nicht um schlecht konstruierten, für Katastrophen anfälligen Code. Es handelt sich um den exakt gleichen Code wie in Ihrem zweiten Beispiel, jedoch mit einer anderen Gehäuse-Konvention. Ich habe Ihr zweites Codebeispiel bearbeitet und mit meiner Gehäusekonvention in mein OP gestellt. Ersetzen Sie das bitte durch Ihr erstes Codebeispiel.
oscilatingcretin
5
@oscilatingcretin: Das erste Codebeispiel zeigt nicht schlecht konstruierten Code, sondern Code, der von einem Team geschrieben wurde, in dem jeder Entwickler seinem eigenen Stil folgte. Dies geschieht bei zu vielen Codebasen, wenn genügend Zeit zur Verfügung steht (z. B. fünf Jahre). Hinweis: Haben Sie Folgendes verpasst? "Tatsache ist, dass der Code auf diese Weise noch viel besser lesbar ist und dass dies auch dann der Fall wäre, wenn andere Standards verwendet würden." ?
Arseni Mourzenko
6
@oscilatingcretin Es gibt zahlreiche Studien, die belegen, dass die kognitive Anstrengung, die erforderlich ist, um etwas zu verstehen, das Sie lesen, durch Konsistenz erheblich verringert wird. Regelmäßige Prosa, schlechte Rechtschreibung, schlechte Zeichensetzung und miese Grammatik erschweren das Lesen - ob sie es bewusst bemerken oder nicht. Code ist schwer genug zu lesen, ohne es zu erschweren - die Einhaltung des "gemeinsamen Standards" (für den von Ihnen gewählten Technologie-Stack) erhöht die Gesamtkonsistenz und macht Neuronen frei, sich auf das wichtige Geschäft zu konzentrieren, was der Code tut, anstatt wie es steht geschrieben.
Bevan
10

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.

tdammers
quelle
Es sieht also so aus, als ob einige ältere Sprachen den Weg für Codierungsstandards zukünftiger Sprachen geebnet haben (wie Ihr C / C # -Beispiel). Das ist am bedauerlichsten, da das Verfolgen der Groß- und Kleinschreibung von Variablen und Objektelementen nur eine unnötige Komplexität zur Folge hat, auf die verzichtet werden kann.
oscilatingcretin
4
@oscilatingcretin Wenn jeder dieselbe Konvention verwendet, erhöht dies nicht die Komplexität, die Konvention wird Teil Ihres mentalen Modells für die betreffende Sprache UND vereinfacht die Verwendung dieser Sprache. Das ist nachweisbar und messbar.
Mr.Mindor
Ich wollte dich abstimmen, aber du sagst zuerst, dass es egal ist, dann schreibst du mehrere Absätze, in denen erklärt wird, warum es wichtig ist. Wenn Sie das "es ist egal" am Anfang löschen, werde ich Sie abstimmen.
Tulains Córdova
10

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.

Jamie F
quelle
Eine Reihe von Projekten, an denen ich gearbeitet habe, geben so etwas in ihrem Styleguide an.
Anaximander
7

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.

Adrian Schneider
quelle
"Wenn ich eine großgeschriebene Variable sehe, wird eine fundierte Vermutung diktieren, dass ich sie instanziieren muss, um sie zu verwenden." Ich verstehe nicht. Wie würden Sie glauben, dass Sie eine großgeschriebene Variable instanziieren müssen, bevor Sie sie verwenden? Weil es aussieht wie ein Klassenname? Sie kennen also den Unterschied zwischen MyClass MyClass = nullund nicht class MyClass { }?
oscilatingcretin
3
Ja, ich sehe den Unterschied. Die Konvention existiert, um Mehrdeutigkeiten zu vermeiden. var car = new Car();Wie in meiner letzten Zeile - warum nicht deutlich machen?
Adrian Schneider
3
@oscilatingcretin Es gibt natürlich einen Unterschied. Das menschliche Gehirn profitiert jedoch von visuellen Hinweisen, die ein Computerparser nicht benötigt. Es scheint, als würden Sie die Notwendigkeit von Konventionen / Standards in Frage stellen. Dies ist eine gültige, wenn auch andere Frage als die, die Sie ursprünglich gestellt haben.
Andres F.
2

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

N4TKD
quelle
1
Hast du meine Frage vollständig gelesen? Schauen Sie zum Ende, wo ich sagte:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin
8
Ja und ja, es ist wichtig, der nächste Programmierer sollte niemals an NuggetCount denken müssen. Sie sollten in der Lage sein, auf den Namen zu schauen und es zu sagen. Ein gutes Buch zum Lesen ist "Clean Code". Sie sollten in der Lage sein, den Code wie eine Geschichte zu lesen und zu wissen, was passiert.
N4TKD
2
@oscilatingcretin Ich denke, die Frustration, die Sie sehen, wenn Leute etwas andere Fragen beantworten als Sie, ist ein Beweis für die Verwirrung, die entstehen kann, wenn Sie akzeptierte Konventionen brechen.
Mr.Mindor
7
Konventionen tragen Bedeutung. Wenn NuggetCount gemäß der Konvention eine Eigenschaft impliziert, bedeutet dies, dass der Gültigkeitsbereich über den einer lokalen Variablen hinausgeht. Das heißt, ich muss mehr recherchieren, um diesen Umfang zu bestimmen. Ich muss feststellen: Gibt es Nebenwirkungen, wenn ich es ändere? Kann ich darauf vertrauen, dass sein Wert nicht von einem anderen Thread geändert wird, während ich ihn verwende? nuggetCount impliziert lokalen Geltungsbereich und ich sollte davon ausgehen können, dass die gesamte Story lokal ist.
Mr.Mindor
5
@oscilatingcretin JA! Genau! Ich vertraute darauf, dass das, was sie schrieben, der Konvention entsprach und alles mitnahm, was dazu gehörte. Ich vertraute darauf, dass sie Teil des Teams sind, und ich könnte die Vorteile dieser Konvention nutzen (zu wissen, was nuggetCount auf einen Blick bedeutet). Wenn sie dies nicht tun, tue ich wahrscheinlich das, was Ihre Kollegen getan haben: Ich versuche, den Verantwortlichen zu erziehen und ich verschwende nächstes Mal mehr Zeit, wenn ich ihnen folgen muss, indem ich nicht vertraue. Indem sie sich nicht an die Konvention halten, produzieren sie weniger lesbaren und weniger wartbaren Code. Haben Sie einen Grund, sich gegen die Konvention zu stellen?
Mr.Mindor
0

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.

John
quelle
-2

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.

Ayvango
quelle
-2

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.

ikh
quelle
-3

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.

Phkahler
quelle
Ich denke, das ist eine sehr gute Antwort und ich verstehe die Abstimmungen nicht. Es ist eine logische Antwort - basierend auf Fakten, wie sie vom OP angefordert wurden. Wenn Sie abstimmen, erklären Sie sich bitte. Die Umschalttaste, die überall gedrückt wird, ist gewaltig. Denken Sie darüber nach, fast jedes Wort, das Sie in Ihren Code eingeben, startet PascalCase und für jedes Wort benötigen Sie einen weiteren Tastendruck. Wenn Sie minimalistisch und effektiv sein möchten, ist es sinnvoll, unnötige Umschalttasten zu entfernen. Und logischerweise möchten Sie produktiver sein, was bedeutet, dass Sie von meinem Standpunkt aus weniger Tasten drücken müssen. Warum mehr drücken?
Am
-3

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.

Filipe
quelle
3
dies scheint nicht zu bieten alles wesentliche über gemacht Punkte und erläutert vor 11 Antworten
gnat