JavaScript-Namenskonventionen [geschlossen]


257

Ich weiß, dass es viele Kontroversen gibt (vielleicht keine Kontroversen, aber zumindest Argumente), welche Namenskonvention für JavaScript die beste ist.

Wie benennen Sie Ihre Variablen, Funktionen, Objekte und dergleichen?

Ich werde meine eigenen Gedanken darüber weglassen, da ich JS schon lange nicht mehr gemacht habe (nur ein paar Jahre), und ich habe gerade die Anfrage erhalten, ein Dokument mit Namenskonventionen zu erstellen, die in unseren Projekten bei der Arbeit verwendet werden sollen . Ich habe mich also umgesehen (googeln) und es gibt so viele verschiedene Meinungen.

Die Bücher, die ich über JS gelesen habe, verwenden auch unterschiedliche Namenskonventionen, aber alle sind sich in einem Punkt einig: "Finden Sie, was zu Ihnen passt, und bleiben Sie dabei." Aber jetzt, wo ich so viel gelesen habe, habe ich festgestellt, dass ich einige der anderen Methoden ein bisschen besser mag als das, was ich jetzt gewohnt bin.


Ein aktueller Leitfaden zu Namenskonventionen für den gesunden Menschenverstand in JS: robinwieruch.de/javascript-naming-conventions
Robin Wieruch

Antworten:


202

Ich folge Douglas Crockfords Code-Konventionen für Javascript. Ich verwende auch sein JSLint- Tool, um die Einhaltung dieser Konventionen zu überprüfen.


30
JSLint kann für viele Entwickler zu radikal und restriktiv sein, dann kann JSHint die bessere Wahl sein.
Pavel Hodek

7
Crockford geht nicht auf diese Detailebene ein, aber was ist mit Variablen, die zufällig mit einem Großbuchstaben beginnen, weil sie sich auf ein Akronym beziehen - sollte der erste Buchstabe oder das gesamte Akronym in Kleinbuchstaben geschrieben werden? Beispiel: ECBhandlevs. ecbHandle(es spielt keine Rolle, was die EZB bedeutet).
Dan Dascalescu

13
Obwohl es ein guter Link ist, kann ich nicht glauben, dass eine "Linkantwort" so viele Stimmen hat. Sie können zumindest die relevanten Teile der verlinkten Seite extrahieren und formatieren.
Adrien Be

2
Ich denke, er macht es gut mit dem Link. Wenn Sie so besorgt sind, sollten Sie den Beitrag bearbeiten.
Nckbrz

4
Ich sehe wirklich zu Crockford auf, aber seine Codekonventionen scheinen sehr veraltet zu sein. Ich würde raten, auf @PavelHodek Antwort weiter unten in der Liste zu schauen
Per Hornshøj-Schierbeck

160

Wie Geoff sagt, ist das, was Crockford sagt, gut.

Die einzige Ausnahme, der ich folge (und die ich häufig gesehen habe), ist die Verwendung von $ varname, um ein jQuery-Objekt (oder eine andere Bibliothek) anzugeben. Z.B

var footer = document.getElementById('footer');

var $footer = $('#footer');


7
Ich benutze $ auch dafür. Ich sehe oft Leute, die $ verwenden, um eine zwischengespeicherte Kopie eines Objekts anzuzeigen. Ich habe immer angenommen, dass es ein Wortspiel ist. Cache> "Bargeld"> $
Shawn Whinnery

1
Dies ist möglicherweise nicht die beste Idee, wenn Sie AngularJS verwenden. Den Kerndiensten wird '$' vorangestellt
Filip Sobczak

2
Ich empfehle dringend, KEINE Sonderzeichen in Variablennamen zu verwenden. Viele Frameworks verwenden insbesondere $.
Nckbrz

1
@nixxbb Das ist in Ordnung, wenn Sie Variablen zu Recht erfassen - was auch anständige Frameworks tun.
Andre Figueiredo

1
Ich sehe, dass Crockfords Gildenlinien erwähnen: "Verwenden Sie _ underbar nicht als erstes oder letztes Zeichen eines Namens. Es soll manchmal die Privatsphäre anzeigen." Ich persönlich benutze die Unterleiste, um private Mitglieder anzuzeigen. Ist das eine schlechte Praxis? Gibt es eine Alternative?
Ian G

112

Sie können diesem Google JavaScript Style Guide folgen

Verwenden Sie im Allgemeinen functionNamesLikeThis, variableNamesLikeThis, ClassNamesLikeThis, EnumNamesLikeThis, methodNamesLikeThis und SYMBOLIC_CONSTANTS_LIKE_THIS.

BEARBEITEN: Siehe schöne Sammlung von JavaScript Style Guides und Beautifiers .


15
Ich bin mir nicht sicher, ob ich dem voll und ganz zustimme, wenn man bedenkt, dass sie Dart und GWT entwickelt haben (die Javascript-API für Chrome-Erweiterungen ist auch sehr Java-ähnlich). Für einige Teams in Google besteht der beste Weg, Javascript zu entwickeln, darin, es in einer anderen Sprache zu schreiben.
Badunk

2
Ich fand Googles private Namenskonvention immer seltsam , anstatt _fooBarsie fooBar_- Microsoft hat es richtig gemacht: asp.net/ajaxlibrary/act_contribute_codingStandards.ashx
Daniel Sokolowski

3
@ DanielSokolowski Was ist mit Intellisense? Wenn Sie einer großen Anzahl von Variablen einen Unterstrich voranstellen, ist dies nur ein weiteres Zeichen, das Sie bei jedem Zugriff auf diese Variablen eingeben müssen. Am Ende sieht Ihre Intellisense-Liste übersichtlicher aus und es ist nur ein bisschen schneller, das zu finden, was Sie brauchen.
FreeAsInBeer

@FreeAsInBeer stimmt mit dem zusätzlichen Charakter überein, aber ich denke nicht, dass es schneller ist. Typing , _wenn private Vars Referenzierung führen würde intellisense sofort die Ergebnisse zu begrenzen; Am Ende dachte ich, es sei eine persönliche Präferenz.
Daniel Sokolowski

1
Vielen Dank für den Link zur Liste der Styleguides. Ich weiß nicht, ob es sich lohnt, ausschließlich zu folgen oder wie ich mich noch entscheiden soll oder ob ich eine Verschmelzung verwenden soll. Aber zu wissen, wo man mehrere an einem Ort findet, ist ein wahrer Segen.
Roger_S

9

Eine Konvention, die ich ausprobieren möchte, ist die Benennung statischer Module mit dem Präfix 'the'. Überprüfen Sie dies heraus. Wenn ich das Modul eines anderen verwende, ist es nicht leicht zu erkennen, wie ich es verwenden soll. z.B:

define(['Lightbox'],function(Lightbox) {
  var myLightbox = new Lightbox() // not sure whether this is a constructor (non-static) or not
  myLightbox.show('hello')
})

Ich denke darüber nach, eine Konvention auszuprobieren, bei der statische Module 'the' verwenden, um ihre Präexistenz anzuzeigen. Hat jemand einen besseren Weg gesehen? Würde so aussehen:

define(['theLightbox'],function(theLightbox) {
  theLightbox.show('hello') // since I recognize the 'the' convention, I know it's static
})

6

Ich denke, dass neben einigen Syntaxbeschränkungen; Die Argumentation der Namenskonventionen ist sehr sprachunabhängig. Ich meine, die Argumente für c_style_functions und JavaLikeCamelCase könnten genauso gut umgekehrt verwendet werden. Es ist nur so, dass Sprachbenutzer dazu neigen, den Sprachautoren zu folgen.

Trotzdem denke ich, dass die meisten Bibliotheken in etwa dazu neigen, einer Vereinfachung von Javas CamelCase zu folgen. Ich finde die Ratschläge von Douglas Crockford geschmackvoll genug für mich.


2

Das ist eine individuelle Frage, die davon abhängen kann, wie Sie arbeiten. Einige Leute möchten den Variablentyp am Anfang der Variablen setzen, wie "str_message". Und einige Leute verwenden gerne Unterstriche zwischen ihren Wörtern ("my_message"), während andere sie gerne durch Großbuchstaben ("myMessage") trennen.

Ich arbeite oft mit riesigen JavaScript-Bibliotheken mit anderen Leuten zusammen, daher müssen Funktionen und Variablen (mit Ausnahme der privaten Variablen in Funktionen) mit dem Namen des Dienstes beginnen, um Konflikte zu vermeiden, wie "guestbook_message".

Kurz gesagt: Englisch, Kleinbuchstaben, gut organisierte Variablen- und Funktionsnamen sind meiner Meinung nach vorzuziehen. Die Namen sollten ihre Existenz beschreiben, anstatt kurz zu sein.


2
"Funktionen und Variablen (mit Ausnahme der privaten Variablen in Funktionen) müssen also mit dem Namen des Dienstes beginnen, um Konflikte zu vermeiden." Diese Aussage ist ungenau . Sie können Funktionen und Objekte mit "Namespace" korrekt verwenden, die nicht durch mehrere Javascript-Frameworks bluten. Es gab eine sehr gute Präsentation darüber, wie dies erreicht werden kann von MIX11 channel9.msdn.com/Events/MIX/MIX11/OPN08
Chris Marisic
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.