it-swarm.com.de

Warum die kürzliche Verlagerung zum Entfernen / Weglassen von Semikolons aus Javascript?

In letzter Zeit scheint es in Mode zu sein, Semikolons in Javascript wegzulassen. Vor einigen Jahren gab es einen Blog-Beitrag , der betonte, dass in Javascript Semikolons sind optional und der Kern des Beitrags schien zu sein, dass Sie sich nicht mit ihnen beschäftigen sollten, weil sie sind unnötig. Der häufig zitierte Beitrag gibt keine zwingenden Gründe an, sie nicht zu verwenden, nur dass das Auslassen nur wenige Nebenwirkungen hat.

Sogar GitHub ist gesprungen auf dem No-Semicolon-Zug, der in einem intern entwickelten Code weggelassen werden muss, und ein kürzlich festgeschriebenes Commit für das zepto.js-Projekt durch seinen Betreuer wurde entfernt alle Semikolons aus der Codebasis. Seine Hauptbegründungen waren:

  • es ist eine Frage der Präferenz für sein Team;
  • weniger tippen

Gibt es andere gute Gründe, sie wegzulassen?

Ehrlich gesagt sehe ich keinen Grund, sie wegzulassen, und schon gar keinen Grund, den Code erneut zu lesen, um sie zu löschen. Es geht auch gegen ( Jahre von ) empfohlene Praxis , für die ich das Argument "Frachtkult" nicht wirklich kaufe. Also, warum all der jüngste Semikolon-Hass? Droht ein Mangel? Oder ist dies nur die neueste Javascript-Modeerscheinung?

86
Jonathan

Ich nehme an, mein Grund ist der lahmste: Ich programmiere gleichzeitig in zu vielen verschiedenen Sprachen (Java, Javascript, PHP) - für die ';' Also anstatt meine Finger und Augen zu trainieren, dass das ';' wird für Javascript nicht benötigt, ich füge einfach immer das ';'

Der andere Grund ist die Dokumentation: durch Hinzufügen des ';' Ich sage mir ausdrücklich, wo ich das Ende der Aussage erwarte. Andererseits benutze ich auch die ganze Zeit {}.

Das ganze Argument der Byteanzahl finde ich irritierend und sinnlos:

1) für gängige Bibliotheken wie jquery: Verwenden Sie das Google CDN und die Bibliothek befindet sich wahrscheinlich bereits im Browser-Cache

2) Versionieren Sie Ihre eigenen Bibliotheken und stellen Sie sie so ein, dass sie für immer zwischengespeichert werden.

3) gzip und minimieren, wenn wirklich, wirklich notwendig.

Aber wirklich, wie viele Websites haben als größten Geschwindigkeitsengpass die Download-Geschwindigkeit ihres Javascript? Wenn Sie für eine Top-100-Site wie Twitter, Google, Yahoo usw. arbeiten. Der Rest von uns sollte sich nur um die Codequalität kümmern, nicht um Semikolon-Religionskriege.

67
Pat

Dies erleichtert die Verkettung von Methoden und das Festschreiben von Unterschieden

Nehmen wir also an, ich frage nach und habe es getan

$('some fancy selector')
  .addClass()
  .attr();

Wenn ich etwas hinzufügen möchte nd mein zeilenbasiertes Commit-Diff klein halten möchte, muss ich es über attr hinzufügen. Es ist also ein Gedanke länger als nur "am Ende hinzufügen". Und wer will denken? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

Aber wenn ich die Semikolons fallen lasse, kann ich sie einfach anhängen und einen Tag nennen

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Wenn ich mich entscheide, die letzte Methode zu deaktivieren, muss ich das Semikolon nicht neu zuweisen und mein Commit erneut verschmutzen.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Gegen das Uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();
40
Mark Canlas

Semikolons in JavaScript sind optional

Mein persönlicher Grund, keine Semikolons zu verwenden, ist OCD.

Wenn ich Semikolons verwende, vergesse ich 2% davon und muss sie ständig überprüfen/wieder hinzufügen.

Wenn ich keine Semikolons verwende, habe ich nie versehentlich einen eingefügt, damit ich sie nie überprüfen/entfernen muss.

23
Raynos

Es gibt keine Informationsüberflutung, nur schlechtes Design.

- Edward Tufte

Es ist eine allgemeine Regel im Grafikdesign , unnötige Elemente und Verzierungen wegzulassen, um das Rauschen zu reduzieren.

Weniger visuelle Elemente auf dem Bildschirm bedeuten weniger Arbeit für unser Gehirn, um die tatsächlich nützlichen Informationen zu analysieren.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

Ein übertriebenes Beispiel natürlich, aber es veranschaulicht das allgemeine Prinzip: Zusätzliche visuelle Elemente sollten genau dann hinzugefügt werden, wenn sie einem Zweck dienen. Erfüllen Semikolons also einen Zweck?

Die historischen Gründe für die Verwendung von Semikolons in JavaScript waren:

  • Behalten Sie die Ähnlichkeit mit C/Java bei
  • Vermeiden Sie Kompatibilitätsprobleme mit schlecht geschriebenen Browsern und Tools
  • Hilfe für Menschen und Maschinen bei der Erkennung von Codefehlern
  • Das automatische Einfügen von Semikolons führt zu einem Leistungsverlust

Die Kompatibilitätsprobleme sind heute so gut wie kein Problem. Moderne Linters können Codefehler erkennen genauso gut ohne Semikolons. Die Ähnlichkeit mit C/Java/PHP kann immer noch eine Überlegung sein (siehe akzeptierte Antwort von Pat), aber nur weil andere Sprachen überflüssige Syntaxelemente enthalten, heißt das nicht, dass wir sie in JavaScript behalten sollten, zumal viele Andere Sprachen (Coffeescript, Python, Ruby, Scala, Lua) benötigen sie nicht.

Ich habe einen kurzen Test durchgeführt, um festzustellen, ob es in V8 einen Leistungsverlust gibt. Dies ist Io.js, das eine 41-MB-JavaScript-Datei (Lodash 100-mal wiederholt) mit Semikolons und dann entfernten Semikolons analysiert:

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

Jeder muss seinen bevorzugten Codierungsstil für seine Projekte festlegen, aber ich sehe keinen greifbaren Vorteil mehr in der Verwendung von Semikolons. Um das visuelle Rauschen zu reduzieren, habe ich aufgehört.

18
justmoon

Ich habe kürzlich einen Parser/Analysator für JavaScript geschrieben, in dem ich ASI sorgfältig implementieren musste, und ich habe auch meine Kopie von Crockfords JavaScript: The Good Parts aktiviert mein Bücherregal, das immer mit Semikolons befürwortet. Die Absicht war gut, aber in der Praxis hilft es nicht immer.

Offensichtlich sind die Leute, die Frameworks wie jQuery, zepto usw. schreiben, JavaScript-Syntax-Master und kennen daher den Unterschied zwischen:

return
{
    status: true
};

und

return {
    status: true
};

JavaScript ist zwar leistungsfähig, aber auch eine Anfängersprache und viel Glück, wenn Sie dies jemandem erklären, der gerade lernt, was eine for -Schleife ist. Wie bei der Einführung der meisten Menschen in eine neue Fähigkeit gibt es einige komplexere Dinge, die Sie nicht sofort erklären möchten. Stattdessen möchten Sie einen "Frachtkult" -Glauben an bestimmte Dinge vermitteln, um sie auf den Weg zu bringen. Sie haben also zwei Möglichkeiten, wenn Sie einem Anfänger das Schreiben von JavaScript beibringen:

  1. Sagen Sie ihnen "Befolgen Sie diese eine Regel und fragen Sie nicht warum" und fordern Sie sie auf, am Ende jeder Zeile ein immer Semikolon einzufügen. Leider hilft dies im obigen Beispiel oder in einem anderen Beispiel, in dem ASI im Weg steht, nicht weiter. Und Herr oder Frau Anfänger Programmierer wird verwirrt, wenn der obige Code fehlschlägt.
  2. Sagen Sie ihnen "Befolgen Sie diese beiden Regeln und fragen Sie nicht warum", und fordern Sie sie auf, sich nicht mit Semikolons am Ende jeder Zeile zu beschäftigen und stattdessen immer a) Folgen Sie return mit a { und b) Wenn eine Zeile mit einem ( beginnt, stellen Sie ihr einen ; voran.

Wenn Sie Option 2 auswählen, müssen Sie die Regeln für den "Frachtkult" besser befolgen (dies führt zu sehr wenigen ASI-bezogenen Fehlern). Selbst wenn Sie das Thema genau verstehen, werden weniger nicht benötigte Zeichen auf dem Bildschirm angezeigt.

17
Kevin McCormick

Die Auswahl einer Programmierkonvention entspricht praktisch der Auswahl einer Teilmenge der Zielsprache. Wir alle tun dies aus den üblichen Gründen: Lesbarkeit, Wartbarkeit, Stabilität, Portabilität usw. des Codes - und dabei möglicherweise die Flexibilität beeinträchtigen. Diese Gründe sind echte Geschäftsgründe.

Gründe wie "Speichern von Tastenanschlägen" und "Programmierer sollten die JavaScript-Regeln lernen" sind marginale geschäftliche Gründe, weshalb sie wenig praktisches Gewicht haben.

In meinem Fall musste ich mich sehr schnell mit JavaScript vertraut machen, daher war es zu meinem Vorteil, eine begrenzte Teilmenge der Sprache zu nutzen. Also entschied ich mich für die JSLint-Teilmenge von JavaScript, schaltete die Rockstar-Apps JSLinter in Eclipse auf die restriktivsten Einstellungen ein, die ich aushalten konnte, und habe nicht zurückgeschaut.

Ich bin dankbar, dass ich die Details des Unterschieds zwischen "==" und "===" oder die Details der Semikolon-Einfügung vermeiden kann, da ich bereits eine meilenhohe Aufgabenliste habe und diese Details nicht Helfen Sie dabei, diese Aufgaben eine Sekunde früher zu erledigen.

Das Wichtigste an einer Konvention ist natürlich die Konsistenz, und wenn man sie als Teilmenge der Sprache betrachtet, kann man diesen Imperativ verstärken. Und obwohl dies möglicherweise nicht zur Beantwortung der Frage des OP beiträgt, denke ich, dass dies bei der praktischen Ausarbeitung hilfreich sein könnte.

8
mjhm

Eine ziemlich alte Frage, aber ich bin überrascht, dass niemand etwas erwähnt hat:

Minifizierung : Wenn Sie zufällig ein JavaScript-Snippet minimieren, das die Anweisungen nicht explizit mit einem Semikolon beendet, fällt es Ihnen möglicherweise schwer, herauszufinden, was mit einem Snippet nicht stimmt Das hat gerade vor der Minifizierung funktioniert und funktioniert jetzt nicht mehr.

Ambiguity : Semikolons sind optional, wahr. Wenn Sie sie jedoch aus dem Quellcode entfernen, können Sie dem Parser einige mehrdeutige Szenarien überlassen, um selbst zu entscheiden. Wenn Sie 100 Codezeilen für einen Online-Shop schreiben, spielt dies möglicherweise keine Rolle, aber ernstere Aufgaben erfordern eine 100% ige Klarheit.

Vor langer Zeit habe ich eine sehr schöne Analogie über etwas anderes gelesen, aber es ist auch in diesem Fall sehr wahr: (In unserem Fall) Das Eliminieren der Semikolons ist wie das Überqueren an einer roten Ampel. Sie könnten am Ende in Ordnung sein oder von einem LKW angefahren werden.

Warum wird es heutzutage immer beliebter?

Ich persönlich glaube, dass das Ausführen von JavaScript auf der Serverseite viele Auswirkungen auf die JavaScript-Community selbst hatte. In unserem Fall wird offensichtlich niemand das JavaScript auf der Serverseite minimieren (da der Quellcode nicht an den Webbrowser des Clients gesendet werden soll), sodass es viel sicherer aussieht, keine Semikolons zu haben. Die anderen Entwickler, die aus diesen Büchern, Artikeln und Videos lernen, lehnen jedoch leider die Tatsache ab, dass JavaScript auf der Serverseite nicht genau mit JavaScript auf der Clientseite identisch ist.

6
53777A

Es gibt gute Gründe, sie beizubehalten.

Sie sind nicht wirklich optional. JS kann sie mit automatischer Semikoloneinfügung wieder hinzufügen, wenn sie fehlen, aber das ist nicht dasselbe.

Douglas Crockfords JavaScript: The Good Parts sagt bei zwei verschiedenen Gelegenheiten, dass es eine schlechte Idee ist. Das automatische Einfügen von Semikolons kann Fehler in Ihrem Programm verbergen und zu Mehrdeutigkeiten führen.

JSLint genehmigt nicht.

3
Encaitar

JavaScript benötigte seit über einem Jahrzehnt keine Semikolons mehr, um Anweisungen zu beenden. Dies liegt daran, dass Zeilenumbrüche als Anweisungsterminatoren betrachtet werden (ich glaube, dies wird auch in frühen ECMAScript-Spezifikationen erwähnt). Es ist wirklich sehr sinnvoll, zumal es wirklich keinen guten Grund gibt [den ich kenne], warum JavaScript häufig Semikolons verwenden müsste, aber keine anderen interpretierten deklarativen Sprachen wie Ruby oder Python.

Das Erfordernis von Semikolons kann das Schreiben eines Parsers für eine Sprache erleichtern, aber wenn jeder Interpreter das Weglassen von Semikolons unterstützt, worum geht es dann genau?

Es kommt darauf an, wie kompetent ein Programmierer ist: Wenn Sie wissen, dass Sie ein Semikolon weglassen können, können Sie dies tun, um zu verstehen, dass es möglicherweise Konsequenzen gibt oder nicht. Menschen sind Entscheidungsmaschinen und fast alle Entscheidungen erfordern Kompromisse oder Kompromisse. Der Nachteil, nur Semikolons um Ihren Code zu werfen (selbst an Stellen, an denen sie nicht benötigt werden), besteht darin, dass Ihr Code weniger lesbar wird (je nachdem, wen Sie fragen) und JSLint sich nicht beschwert (wen interessiert das?) ). Auf der anderen Seite ist der Nachteil des Weglassens von Semikolons die Tatsache, dass 90% der JavaScript-Programmierer Sie dafür bestrafen, aber Sie werden möglicherweise mehr Spaß daran haben, JavaScript zu schreiben.

Was klingt für dich besser? fundierte Entscheidungen treffen oder blinde Entscheidungen treffen/Herdenmentalität?

3
Ravenstine

Ich habe zwei Theorien:

EIN)

Die Sache bei dieser Auswahl ist, dass Sie früher, als JSLint usw. anwendbar war, viel Zeit damit verbracht haben, obskure Syntaxfehler zu erkennen, oder eine angemessene Zeit damit verbracht haben, eine Standardrichtlinie für Code durchzusetzen.

Wenn wir uns jedoch mehr dem nit Test - gesteuerten Code und der kontinuierlichen Integration zuwenden, hat sich die Zeit (und die menschliche Interaktion), die erforderlich ist, um einen Syntaxfehler zu erkennen, massiv verringert. Die Rückmeldungen von Tests zeigen schnell an, ob Ihr Code wie erwartet funktioniert, lange bevor er sich einem Endbenutzer nähert. Warum sollten Sie also Zeit damit verschwenden, optionale Ausführlichkeit hinzuzufügen?

B)

Faule Programmierer werden alles tun, um kurzfristig ihr eigenes Leben zu erleichtern. Weniger tippen -> weniger Aufwand -> einfacher. (Wenn Sie kein Semikolon verwenden müssen, wird der rechte Ringfinger nicht belastet, und es wird eine gewisse RSI vermieden.).

(NB. Ich bin nicht einverstanden mit der Idee, etwas wegzulassen, das eindeutig eine Aussage).

2
Ed James

Ich lasse sie nicht aus, aber ich ändere die Regeln, wann sie eingefügt werden sollen.

Die Regeln, die die meisten Leute verwenden, sind

  • Vor jedem Zeilenende
  • Außer die Zeile endet mit einem } kommt aus einer Funktionsanweisung
  • Aber nur eine Funktionsanweisung, keine Zuordnung zu einem Funktionsliteral

Meine Regel lautet: Am Anfang jeder einzelnen Zeile beginnend mit einer öffnenden Klammer.

Meins ist einfacher, daher leichter zu verfolgen und weniger anfällig für Fehler. Auch die geringe Anzahl von Semikolons macht es einfach, Fehler zu finden, die durch Auslassen entstehen.


Ein weiteres Argument ist, dass das berüchtigte return\nvalue Fehler kommt von nicht über ASI zu wissen. Meine Regel zwingt Sie dazu, über ASI Bescheid zu wissen, sodass Personen, die meine Regel verwenden, weniger wahrscheinlich in die Falle dieses Fehlers geraten.

0
flying sheep

Byteanzahl. Sie sehen, böswillige Menschen versuchen normalerweise, so viel in eine einzelne Codezeile zu passen. Technisch gesehen wäre dies ohne Semikolons nicht möglich. Ich gehe davon aus, dass dies eher eine Sicherheitsmaßnahme als nur eine programmatische Anforderung ist. Irgendwie würde dies XSS erheblich reduzieren, wenn es eher eine Anforderung als ein Vorschlag wird.

0
Supreme Dolphin