it-swarm-eu.dev

Namenskonventionen: camelCase versus underscore_case? Was denkst du darüber?

Ich benutze underscore_case seit ungefähr 2 Jahren und bin kürzlich wegen des neuen Jobs zu camelCase gewechselt (benutze den späteren seit ungefähr 2 Monaten und ich denke immer noch, dass underscore_case besser für große Projekte geeignet ist, an denen viele Programmierer beteiligt sind). hauptsächlich, weil der Code leichter zu lesen ist).

Jetzt verwendet jeder bei der Arbeit camelCase, weil (so heißt es) der Code eleganter aussieht.

Was denkst du über camelCase oder underscore_case?

p.s. Bitte entschuldigen Sie mein schlechtes Englisch

Bearbeiten

Einige Updates zuerst:

  • die verwendete Plattform ist PHP (aber ich erwarte keine strengen PHP plattformbezogenen Antworten, jeder kann seine Gedanken darüber teilen, welche am besten zu verwenden wäre) warum ich überhaupt hierher gekommen bin)

  • Ich benutze camelCase genauso wie jeden anderen im Team (genau wie die meisten von Ihnen empfehlen)

  • wir verwenden Zend Framework, das auch camelCase empfiehlt

Einige Beispiele (im Zusammenhang mit PHP):

  • Das Codeigniter-Framework empfiehlt underscore_case, und ehrlich gesagt ist der Code leichter zu lesen.

  • ZF empfiehlt camelCase und ich bin nicht der einzige, der der Meinung ist, dass ZF-Code etwas schwieriger zu befolgen ist.

Meine Frage würde also umformuliert:

Nehmen wir einen Fall, in dem Sie die Plattform Foo haben, die keine Namenskonventionen empfiehlt, und der Teamleiter die Wahl hat, eine auszuwählen. Sie sind dieser Teamleiter, warum sollten Sie sich für camelCase entscheiden oder warum underscore_case?

p.s. Vielen Dank an alle für die Prompt-Antworten

70
poelinca

Ich bin damit einverstanden, dass dies in gewissem Maße von der Sprache abhängt, die Sie verwenden. Code sieht in der Regel ordentlicher aus, wenn Ihre Symbolnamen dem gleichen Formatierungsschema folgen wie die integrierten Sprachen und Bestandsbibliotheken der Sprache.

Aber wo es eine Wahl gibt, ziehe ich aus einem einfachen Grund Unterstriche dem Kamelkoffer vor: Ich finde diesen Stil leichter zu lesen. Hier ein Beispiel: Was finden Sie besser lesbar? Diese:

aRatherLongSymbolName

oder dieses:

a_rather_long_symbol_name

Ich finde die Unterstrichversion viel einfacher zu lesen. Mein Gehirn kann die Unterstriche viel leichter ignorieren, als es die Klein-/Großbuchstabengrenzen im Kamelfall erkennen kann, insbesondere wenn die Grenzen zwischen Glyphen liegen, die anderen Glyphen im umgekehrten Fall ähnlich sehen, oder Ziffern (I/l, O/0, t/I, usw). Diese boolesche Variable speichert beispielsweise einen Wert, der angibt, ob ein Iglu mit der richtigen Baugenehmigung erstellt wurde oder nicht (zweifellos ein allgemeiner Anwendungsfall für uns alle):

isIllicitIgloo

Ich finde diese Version a lot leichter zu lesen:

is_illicit_igloo

Vielleicht noch schlimmer als ein schwer lesbarer Symbolname ist ein leicht zu verstehender Symbolname. Gute Symbolnamen sind selbstdokumentierend, was für mich bedeutet, dass Sie sie lesen und ihre Bedeutung auf einen Blick verstehen können sollten. (Ich bin sicher, wir alle lesen zum Ausdrucken Code-Ausdrucke im Bett, aber gelegentlich sind wir auch in Eile.) Bei Kamelsymbolnamen finde ich oft, dass es leicht ist, sie falsch zu lesen und den falschen Eindruck von a zu bekommen Symbolsemantik.

84
Simon Whitaker

Ich denke, Sie sollten die Namenskonvention verwenden, die von Ihrer Plattform übernommen wurde. underscore_case sieht im C # -Code seltsam aus, als camelCase in Ruby =)

97

Ehrlich gesagt spielt es keine Rolle, solange alle im Team das gleiche Schema verwenden. Die Chancen stehen gut, dass die eine oder andere für Sie natürlicher ist, obwohl die Lesbarkeit des Codes auf lange Sicht wirklich wichtig ist und es dann entscheidend ist, dass jeder die gleichen Namensregeln einhält.

20
dafmetal

Basierend auf einer Antwort die Antwort von John Isaacks:

"Ehrlich gesagt ist der Code leichter zu lesen" Meinung oder Tatsache?

Ich beschloss, etwas zu recherchieren und fand dieses Papier . Was sagt die Wissenschaft zu diesem Thema?

  1. Kamelhülle hat eine größere Wahrscheinlichkeit der Korrektheit als Unterstriche. (Chancen sind 51,5% höher)
  2. Im Durchschnitt dauerte der Kamelfall 0,42 Sekunden länger , was 13,5% länger ist.
  3. Das Training hat keinen statistisch signifikanten Einfluss darauf, wie der Stil die Korrektheit beeinflusst.
  4. Diejenigen mit mehr Training waren schneller bei Identifikatoren im Kamelfallstil.
  5. Das Training in einem Stil wirkt sich negativ auf die Suchzeit für andere Stile aus.

In mein Blogbeitrag zu diesem Thema überprüfe ich das wissenschaftliche Papier und komme zu folgendem Schluss.

Nur die Langsamkeit des Kamelfalls (2) ist für die Programmierung wirklich relevant, wobei die anderen Punkte aufgrund von als irrelevant abgetan werden moderne IDEs und eine Mehrheit der camelCase-Benutzer in der Studie. Die Diskussion (zusammen mit einer Umfrage) finden Sie im Blogbeitrag.

Ich bin gespannt, wie dieser Artikel die Meinung ändern könnte. :) :)

20
Steven Jeuris

Kopiere die klügsten Jungs

Kopieren Sie bei Programmiersprachen den Stil des Entwicklers der Sprache.

Zum Beispiel codiere ich C genau so, wie es in K & R gemacht wird.

Wenn dann jemand versucht, ein langweiliges Gespräch im Codierungsstil zu beginnen, kann ich ihm sagen, "sprechen Sie das mit Dennis Ritche an und lassen Sie mich wissen, was er sagt."

11
Mark Harrison

Im Allgemeinen bevorzuge ich camelCase. Das liegt jedoch daran, dass ich die meiste Zeit meiner Karriere in Sprachen und Umgebungen gearbeitet habe, in denen die Styleguides normalerweise camelCase empfehlen. (Java, ECMAScript, C++). Als PHP Person) haben Sie wahrscheinlich die gegenteilige Präferenz.

Das heißt, wenn Sie über drei oder vier Wörter hinausgehen oder Initialismen wie XMLForExample verwenden, ist es nicht mehr so ​​lesbar.

Deshalb gibt uns Emacs den Brillenmodus.

10
Paul Butcher

camelCase

Dies ist einer der wenigen Orte, an denen ich immer "Typfähigkeit" anstelle von Lesbarkeit wählen werde. CamelCase ist einfach einfacher zu tippen, und wenn ich besser mit den Fingern umgehen kann, gewinnt ich einen leichten Lesbarkeitsgewinn.

vorausgesetzt natürlich, dass das Projekt nicht auf einer vorhandenen Codebasis mit einem anderen Standard aufbaut.

8
AShelly

Es ist eine interessante Frage, über die ich schon oft nachgedacht habe. Aber es gibt keine eindeutige Antwort, denke ich.

Nach den "kulturellen" Konventionen ist es eine gute Wahl. "Kulturell" bedeutet in diesem Fall Konventionen, die im Team/Unternehmen eingerichtet wurden, und sie tragen im Wesentlichen auch die Sprach-/Plattformkonventionen. Es hilft anderen, Ihren Code leicht zu lesen/zu verwenden, und erfordert keinen zusätzlichen Aufwand und keine zusätzliche Zeit, um sich mit dem Verständnis Ihres Codes vertraut zu machen.

Manchmal ist es interessant, akzeptierte Notationen zu brechen. Eines meiner kleinen Projekte (auf Python) habe ich underscored_names für Dienstprogrammfunktionen/"geschützte" Methoden und Java-artige methodNames für Methoden. Mein Team war damit zufrieden :)

7
duros

Kommt auf die Programmiersprache an.

Ich überlege, ob ich im selben Boot den Fall verwenden soll, ob die ungarische Notation verwendet werden soll oder nicht:

  • Python: underscore_case, keine ungarische Notation
  • C++: camelCase, ungarische Notation
6
Lionel

Beide!

Ich entwickle viel in CakePHP und verwende entweder CamelCase oder $underscored_vars Auf folgende Weise (auch außerhalb von CakePHP-Projekten):

  1. Dateinamen - /lowercased_underscored.php Typisch, aber erwähnenswert.
  2. Klassen - class CamelCase extends ParentObject. Beachten Sie, dass bei Verwendung von CamelCase das Anfangszeichen nicht in Kleinbuchstaben geschrieben wird. Ich finde camelCase seltsam auszusehen wirklich.
  3. Variablen - $are_variables_underscored === TRUE;
  4. Variablen, die Instanzen enthalten - $CamelCase = new CamelCase();
  5. Array-Schlüssel - $collection['underscored_keys'];
  6. Konstanten - Ich denke, jeder kann zustimmen, dass Konstanten ALL_CAPS_AND_UNDERSCORED sein sollten.
  7. Methoden - $CamelCase->foo_method_underscored();
  8. statische Methoden - CamelCase::just_like_regular_methods();
6
Stephen

Ich persönlich bevorzuge underscore_case, Weil ich es besser lesbar finde, stimme aber den anderen Antwortenden zu, die darauf hinweisen, dass die Konsistenz mit der vorhandenen Codebasis viel wichtiger ist.

Ich habe jedoch ein Gegenbeispiel für diejenigen, die sagen "Befolgen Sie die Konvention Ihrer Sprache und ihrer Bibliotheken".

In der Vergangenheit haben wir C-Code unter Windows mit underscore_case Geschrieben und PascalCase Win32-Funktionen aufgerufen:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

Die visuelle Unterscheidung zwischen unseren Funktionsnamen und den Funktionsnamen von Microsoft war eher eine Hilfe als ein Hindernis, da deutlich wurde, wann der Code in das "Systemland" ging.

Außerdem konnte ich die Syntaxhervorhebungsregeln meines Editors ändern, um sie in verschiedenen Farben anzuzeigen. Dies gab weitere visuelle Hinweise, wenn ich versuchte, unbekannte Codeabschnitte (oder sogar meine eigenen) zu verstehen.

5
Paul Stephenson

Ich mag Dylans ganz normale Bindestriche, da sie leicht zu tippen und leicht zu lesen sind.

Mögen

result-code := write-buffer(file-stream, some-string)

Aber ich denke, da diese Sprache ziemlich dunkel ist, ist dies eine Art Off-Topic ... :(

5
Kosta

An der Universität wurde mir beigebracht, camelCase zu benutzen. Ich habe in den letzten Jahren einige verschiedene Konventionen verwendet, bevorzuge jedoch camelCase gegenüber allem anderen. Ich denke, ich erinnere mich, dass ich irgendwo gelesen habe, dass camelCase tatsächlich am einfachsten zu lesen und zu verstehen ist.

4
Ross

Persönlich bevorzuge ich camelCase, aber in einigen Schriftarten sind Unterstriche meiner Meinung nach leichter zu lesen.

Ich würde vorschlagen, dass Sie, wenn Sie Präfixe verwenden müssen, um Sätze von Variablen zu unterscheiden, eine Sprache verwenden sollten, mit der Sie Namespaces oder Objekte oder etwas erstellen können, das diese Informationen enthält.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Wenn Sie Typen unterscheiden müssen, können Sie auch eine Sprache verwenden, die sie zulässt.

var intThingy = 7; // :(

int thingy = 7;    // :)

Sobald Sie dies klargestellt haben und den Namen nicht nur als Metadaten verwenden, haben Sie nicht mehr genügend lange Namen, sodass es sehr wichtig ist, ob Sie diesen zusätzlichen Tastendruck bevorzugen oder nicht.

4
Kevin Cantu

Wie die meisten Leute erwähnt haben - Verwenden Sie den vorhandenen Standard. Wenn es sich um ein neues Projekt handelt, verwenden Sie den Standard für die Sprache und die Frameworks, die Sie verwenden werden.

Und seien Sie nicht verwirrt, es geht nicht um Lesbarkeit (was subjektiv ist), es geht darum, konsistent und professionell zu sein. Jeder, der in einer Codebasis mit zahlreichen "Standards" gearbeitet hat, wird verstehen.

4
Colin Goudie

Ich benutze manchmal eine Mischung: module_FunctionName. Alle (nicht statischen) Funktionen in meinen Modulen beginnen mit einer Modulabkürzung.

Zum Beispiel eine Funktion zum Senden des Inhalts eines Puffers auf dem I2C-Bus:

i2c_BufferSend()

Die Alternative i2c_buffer_send zeigt keine ausreichend große Trennung zwischen Präfix und Funktionsname. i2cBufferSend mischt das Präfix zu stark ein (es gibt eine ganze Reihe von I2C-Funktionen in diesem Modul).

i2c_Buffer_send könnte jedoch eine Alternative gewesen sein.

Meine Antwort war, dass Sie sich an das anpassen, was für Ihr Projekt am besten funktioniert (Ihre Sprache, Ihre SW-Architektur, ...), und ich wollte darauf hinweisen, dass das Mischen dieser Stile nützlich sein könnte.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Ich respektiere die Tatsache, dass einige anders denken könnten, aber ich verstehe nicht wirklich, warum.

4
Gauthier

Für Programmiersprachen wie Java, Python, C++ habe ich ein klares Format gewählt:

  • ClassNamesArePascalCase
  • methodNamesAreCamalCase
  • variable_names_are_underscore
  • CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Dadurch kann ich sofort erkennen, womit ich es zu tun habe. Ich habe festgestellt, dass dies nützlich ist, um es für mich selbst zu pflegen, und es sollte für jemanden, der den Code liest, leicht zu befolgen sein. Ich denke, wie andere bereits erwähnt haben, ist Konsistenz am wichtigsten. Daher finde ich mein Format einfach genug, um es zu pflegen und gleichzeitig klar zwischen verschiedenen Arten von Namen zu unterscheiden. Ich könnte mir interface_Names_Are_Like_This und Abstract_Classes_Are_Like_This als mögliche Erweiterungen vorstellen, aber es scheint komplizierter zu sein, zu folgen und vielleicht keine so nützliche Unterscheidung zu treffen.

Ich fand es auch nützlich, streng zu sein und Dinge in PascalCase zu benennen, wie zum Beispiel einen HTML-Parser wie HtmlParser anstelle von HTMLParser oder HTMLparser. Weil ich glaube, dass es einfacher ist, sich an die strenge Regel zu erinnern und die Word-Grenzen klarer zu halten (leider sind Rechtschreibfehler wie HTML oder SQL erforderlich). Ähnlich wie bei camelCase htmlParserMethod anstelle von HTMLParserMethod oder HTMLparserMethod.

UPDATE :

Ich habe seitdem Verwendung gefunden, um diese Regeln um private Variablen zu erweitern. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

In Java bedeutet dies, dass sich private Felder per Definition in einem anderen Namespace befinden als lokale Variablen. Dies bedeutet, dass Sie this. Für private Felder überspringen können. Andere Formate Ich habe das Präfix "m" gesehen, aber diese Formate verwenden auch camelCase für die Variablennamen. Dies ermöglicht mir auch, zwischen Feldern zu unterscheiden, auf die nur von der Klasse intern zugegriffen werden sollte (und es super klar zu machen, wenn es außerhalb der Klasse geschieht object._field_x Sticht heraus).

2
Dandre Allison

Zunächst stimme ich Dafmetal zu. Es ist äußerst wichtig, dass Sie keine unterschiedlichen Programmierstile mischen. Dies in ein und derselben Datei zu tun, ist meiner Meinung nach das Schlimmste, was Sie tun können. Über verschiedene Dateien hinweg ist es ablenkend, aber nicht tödlich.

Das nächste, was Sie tun müssen, ist, Regeln zu benennen, die für die Sprache, in der Sie schreiben, beliebt sind. Mein C++ - Code für instnace sieht anders aus als etwas für Python offensichtlich (PEP8 ist) ein netter Führer hier)

Sie können auch verschiedene Namenskonventionen verwenden, um auf verschiedene Dinge zu verweisen. So sehr Sie wahrscheinlich UPPER_CASE für Konstanten verwenden (dies gilt natürlich nur für bestimmte Sprachen), können Sie this_style für lokale Variablennamen verwenden, während Sie camelCase für Instanz/Mitglied verwenden Variablen. Dies ist möglicherweise nicht erforderlich, wenn Sie Dinge wie self oder this haben.

Aktualisieren

Nehmen wir einen Fall, in dem Sie die Plattform Foo haben, die keine Namenskonventionen empfiehlt, und es ist die Entscheidung des Teamleiters, eine auszuwählen. Sie sind dieser Teamleiter, warum sollten Sie camelCase wählen oder warum underscore_case.

Es gibt wirklich keine Vorteile gegenüber dem anderen. Diese Angelegenheit ist sehr subjektiv und wird, sobald sie vereinbart ist, keinen Unterschied mehr machen. Es gibt immer diese religiösen Kriege um diese kleinen Dinge. Aber wenn Sie sich erst einmal daran gewöhnt haben, scheinen die Diskussionen völlig überflüssig zu sein.

Um Alex Martelli zu einer sehr ähnlichen Angelegenheit zu zitieren:

Sicher, ich werde es müde, in Ruby das dumme "Ende" am Ende jedes Blocks zu tippen (anstatt nur uneindeutig zu sein) - aber dann vermeide ich es, das ebenso alberne ':' zu tippen, das Python benötigt am Start jedes Blocks, das ist also fast eine Wäsche :-). Andere Syntaxunterschiede wie '@foo' versus 'self.foo' oder die höhere Bedeutung von case in Ruby vs Python) sind für mich wirklich genauso irrelevant.

Andere stützen ihre Wahl der Programmiersprachen zweifellos auf solche Themen und generieren die heißesten Debatten - aber für mich ist dies nur ein Beispiel für eines der Parkinson-Gesetze in Aktion ( die Menge an Debatten zu einem Thema ist umgekehrt proportional zur tatsächlichen Bedeutung des Themas ).

Quelle

Wenn Sie der Teamleiter sind, gehen Sie einfach mit einem. Da einer keine Vorteile gegenüber dem anderen hat, können Sie einfach Würfel werfen oder auswählen, was Ihnen besser gefällt.

2
phant0m

Ich habe vor einigen Jahren gelesen, dass Programmierer, die kein Englisch als Muttersprache sprechen, den Unterstrich leichter verstehen, aber ich kann die Referenz nicht finden, und ich habe keine Ahnung, ob sie wahr ist.

2
Ed Harper

Wenn es nach mir ginge, würde ich die Verwendung eines bestimmten Stils nicht erzwingen oder andeuten, da wir als Programmierer in der Lage wären, ein Symbol IfItIsInCamelCase oder in_underscore_space oder sogar in_SomeOtherStyle zu lesen und zu verstehen, was es bedeutet. Ein wenig Zeit damit verbringen zu müssen, das Symbol zu analysieren, ist kein großer Aufwand im großen Schema der Dinge.

Das Hauptargument für eine Konvention ist wohl, dass Sie im Voraus wissen, wie das Format eines Funktions-/Variablennamens lautet, und es nicht nachschlagen müssen - ist es LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Jetzt würde ich diesem Argument entgegenwirken, indem ich sage: "Holen Sie sich ein IDE, das die automatische Vervollständigung im Intellisense-Stil unterstützt!" (Allerdings nicht immer möglich).

Am Ende spielt es jedoch keine Rolle, welchen Stil Sie verwenden, da es dem Compiler/Interpreter egal ist. Wichtig ist, dass der Name nützlich ist:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Drei verschiedene Stile, aber Sie wissen genau, was jeder tut.

1
Skizz

Ich bevorzuge camelCase aus dem dummen Grund, dass ich den größten Teil meiner Entwicklung in Eclipse mache (für Java PHP und JavaScript) und wenn ich Ctrl+ oder Ctrl+ durch Worte hört es tatsächlich an den Grenzen von camelCase auf.

Das heißt: myIntVariable würde von Eclipse als 3 Wörter behandelt, wenn Ctrl+← →durch sie hindurch.

Ich weiß, dass es eine seltsame Eigenart ist, aber ich bevorzuge es, die mittleren Wörter in einem camelCase-Namen bearbeiten zu können.

0
Bassam

Mag albern erscheinen, aber ich mag keine Unterstriche, weil der Unterstrich dünn ist und sich in mehrzeiligem Text versteckt und ich ihn vermisse. Wenn Sie in einigen (vielen) Texteditoren und/oder Entwicklungsumgebungen auf einen Token-Namen doppelklicken, um ihn hervorzuheben, um ihn zu kopieren oder zu ziehen und abzulegen, hebt das System nicht das gesamte Token hervor, sondern nur einen Teil des Tokens zwischen benachbarten Unterstrichen. Das macht mich verrückt.

0
Charles Bretana