Warum die kürzliche Umstellung auf das Entfernen / Weglassen von Semikolons aus Javascript?

Es scheint in letzter Zeit in Mode zu sein, Semikolons aus Javascript wegzulassen. Vor ein paar Jahren gab es einen Blogeintrag , in dem betont wurde, dass Semikolons in Javascript optional sind und der Kern des Beitrags darin bestand, dass Sie sich nicht mit ihnen befassen sollten, weil sie unnötig sind. Der häufig zitierte Beitrag enthält keine zwingenden Gründe, sie nicht zu verwenden, nur dass das Auslassen nur wenige Nebenwirkungen hat.

Sogar GitHub ist auf das No- Semicolon-Modell umgestiegen , da es in jedem intern entwickelten Code weggelassen werden musste, und ein kürzlich von seinem Betreuer vorgenommenes Commit für das Projekt zepto.js hat alle Semikolons aus der Codebasis entfernt. Seine Hauptbegründungen waren:

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

Gibt es noch andere gute Gründe, sie wegzulassen?

Ehrlich gesagt sehe ich keinen Grund, sie wegzulassen, und sicherlich keinen Grund, den Code noch einmal durchzugehen, um sie zu löschen. Es widerspricht auch der ( jahrelangen ) empfohlenen Praxis , für die ich das Argument "Frachtkult" nicht wirklich kaufe. Also, warum all der Semikolon-Hass der letzten Zeit? Steht ein Mangel bevor? Oder ist das nur die neueste Javascript Modeerscheinung?

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

Der andere Grund ist die Dokumentation: durch Hinzufügen des ';' Ich sage mir ausdrücklich, wo die Aussage enden soll. 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: benutze das google cdn und die bibliothek wird sich wahrscheinlich schon im browser cache befinden

2) Versionieren Sie Ihre eigenen Bibliotheken und legen Sie fest, 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-Website wie Twitter, Google, Yahoo, etc. arbeiten, vielleicht. Der Rest von uns sollte sich nur Gedanken über die Codequalität machen, nicht über Semikolon-Religionskriege.

Es erleichtert die Verkettung von Methoden und macht Unterschiede sauberer

Nehmen wir also an, ich bin auf dem laufenden und habe es getan

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

Wenn ich etwas hinzufügen und 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 möchte 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 als Tag bezeichnen

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

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

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

Gegen das Uggo

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

Semikolons in JavaScript sind optional

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

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

Wenn ich keine Semikolons benutze, setze ich sie nie versehentlich ein, damit ich sie nie überprüfen / entfernen muss.

Ich habe kürzlich einen Parser / Analyser für JavaScript geschrieben, bei dem ich ASI sorgfältig implementieren musste, und ich habe auch meine Kopie von Crockfords JavaScript: The Good Parts in meinem Bücherregal, das immer die Verwendung von 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-Syntaxmeister und kennen daher den Unterschied zwischen:

return
{
    status: true
};

und

return {
    status: true
};

JavaScript ist zwar mächtig, aber es ist auch eine Anfängersprache und es ist ein Glück, dies jemandem zu erklären, der gerade lernt, was eine forSchleife ist. Wie bei der Einführung der meisten Menschen in eine neue Fertigkeit gibt es einige komplexere Dinge, die Sie nicht sofort erklären möchten. Stattdessen möchten Sie bestimmten Dingen einen "Frachtkult" beibringen, um sie auf den Weg zu bringen. Sie haben also zwei Möglichkeiten, um einem Anfänger das Schreiben von JavaScript beizubringen:

1. Sagen Sie ihnen "Befolgen Sie diese eine Regel und fragen Sie nicht warum" und fordern Sie sie auf, am Ende jeder Zeile immer ein Semikolon zu setzen . Leider hilft dies nicht im obigen Beispiel oder in einem anderen Beispiel, in dem ASI im Weg steht. Und Anfänger oder Anfängerin Programmierer wird verwirrt, wenn der obige Code fehlschlägt.
2. Sagen Sie ihnen , „diese beiden Regeln folgen und nicht fragen , warum“, sagen sie nicht mit Semikolons am Ende jeder Zeile, und stattdessen zu stören immer a) Folgen returnmit ein {, und b) Wenn eine Zeile beginnt mit einem (, prepend es mit einem ;.

Die Wahl von Option 2 ist ein besserer Satz von "Frachtkult" -Regeln, die befolgt werden müssen (was zu sehr wenigen ASI-bezogenen Fehlern führt), und selbst wenn Sie ein tiefes Verständnis für das Thema haben, werden auf dem Bildschirm weniger nicht benötigte Zeichen angezeigt.

Es gibt keine Informationsüberflutung, nur schlechtes Design.

- Edward Tufte

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

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

let foo = 1

gegen

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

Ein übertriebenes Beispiel natürlich, aber es veranschaulicht das allgemeine Prinzip: Zusätzliche visuelle Elemente sollten nur 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
• Menschen und Maschinen helfen, Codefehler zu erkennen
• Das automatische Einfügen von Semikolons ist mit einer Leistungsstrafe verbunden

Die Kompatibilitätsprobleme sind heute so gut wie kein Problem mehr. Moderne Linters können auch ohne Semikolon Codefehler erkennen . Die Ähnlichkeit mit C / Java / PHP kann immer noch eine Überlegung sein (siehe die akzeptierte Antwort von Pat), aber nur weil andere Sprachen überflüssige Syntaxelemente enthalten, heißt das nicht, dass wir sie in JavaScript belassen 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 eine Leistungsstrafe gab. Dies ist Io.js, das eine 41-MB-JavaScript-Datei (Lodash 100-mal wiederholt) mit Semikolons analysiert und dann mit Semikolons entfernt:

$ 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 spürbaren Vorteil mehr in der Verwendung von Semikolons. Um das visuelle Rauschen zu reduzieren, habe ich aufgehört.

Die Auswahl einer Programmierkonvention entspricht 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 gleichzeitig potenziell auf Flexibilität verzichten. Diese Gründe sind echte Geschäftsgründe.

Gründe wie "Speichern von Tastenanschlägen" und "Programmierer sollten die JavaScript-Regeln erlernen" sind marginale geschäftliche Gründe, sodass 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 habe ich die JSLint-Teilmenge von JavaScript ausgewählt, den Rockstar-Apps-JSLinter in Eclipse auf die restriktivsten Einstellungen eingestellt, die ich aushalten konnte, und habe nicht zurückgeschaut.

Ich bin dankbar, dass ich die Details des Unterschieds zwischen "==" und "===" oder die Details der Semikoloneinfügung vermeiden kann, da ich bereits eine kilometerhohe 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 eine Teilmenge der Sprache betrachtet, kann man diesen Imperativ noch verstärken. Und obwohl dies möglicherweise nicht zur Beantwortung der Frage des OP beiträgt, denke ich, dass es bei der praktischen Formulierung hilfreich sein könnte.

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

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

Mehrdeutigkeit: Semikolons sind optional, wahr. Wenn Sie sie jedoch aus dem Quellcode entfernen, können Sie einige mehrdeutige Szenarien dem Parser überlassen, um selbst zu entscheiden. Wenn Sie 100 Codezeilen für einen Online-Shop schreiben, spielt das vielleicht 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 ein Ü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 Semikolons nicht viel sicherer aussehen, was zutrifft. Die anderen Entwickler, die aus diesen Büchern, Artikeln und Videos lernen, lehnen es leider ab, dass JavaScript auf der Serverseite nicht genau mit JavaScript auf der Clientseite identisch ist.

Es gibt gute Gründe, sie zu behalten.

Sie sind nicht wirklich optional, JS kann sie mit automatischem Semikolon-Einfügen wieder einfügen, wenn sie fehlen, aber das ist nicht dasselbe.

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

JSLint stimmt nicht zu.

JavaScript benötigt seit über einem Jahrzehnt keine Semikolons mehr, um Anweisungen zu beenden. Dies liegt daran, dass Zeilenumbrüche als Abschlusszeichen für Anweisungen gelten (ich glaube, dies wird auch in früheren ECMAScript-Spezifikationen erwähnt). Das macht sehr viel Sinn, zumal es wirklich keinen guten Grund gibt, warum JavaScript häufig Semikolons, aber keine anderen interpretierten deklarativen Sprachen wie Ruby oder Python verwenden muss.

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

Worauf es ankommt, ist, wie kenntnisreich ein Programmierer ist: Wenn Sie wissen, dass Sie ein Semikolon weglassen können, können Sie dies tun, indem Sie 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 (auch an Stellen, an denen sie nicht benötigt werden), ist, dass Ihr Code weniger lesbar wird (je nachdem, wen Sie fragen) und JSLint sich nicht beschwert (wen es interessiert) ). Auf der anderen Seite ist der Kompromiss, Semikolons wegzulassen, die Tatsache, dass 90% der JavaScript-Programmierer Sie dafür züchtigen werden, aber Sie werden am Ende vielleicht mehr Spaß daran haben, JavaScript zu schreiben.

Was hört sich für dich besser an? fundierte Entscheidungen treffen oder blinde Entscheidungen treffen / Herdenmentalität?

Ich habe zwei Theorien:

EIN)

Die Sache bei dieser Wahl ist, dass Sie sich damals, als JSLint usw. anwendbar waren, dafür entschieden, viel Zeit damit zu verbringen, unklare Syntaxfehler abzufangen oder eine angemessene Zeit für die Durchsetzung einer Standardrichtlinie für Code zu verwenden.

Mit zunehmender Hinwendung zu Unit-Test- gesteuertem Code und kontinuierlicher Integration hat sich jedoch die Zeit (und die menschliche Interaktion), die erforderlich ist, um einen Syntaxfehler abzufangen, massiv verringert. Die Rückmeldungen von Tests zeigen schnell an, ob Ihr Code wie erwartet funktioniert, bevor er in die Nähe eines Endbenutzers gelangt. Warum also Zeit verschwenden, um optionale Ausführlichkeit hinzuzufügen?

B)

Faule Programmierer werden kurzfristig alles tun, um sich das Leben zu erleichtern. Weniger Tippen -> weniger Aufwand -> einfacher. (Wenn Sie kein Semikolon eingeben müssen, wird Ihr rechter Ringfinger nicht belastet, und es wird ein gewisses RSIness vermieden.)

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

Ich lasse sie nicht aus, aber ich ändere die Regeln, wenn ich sie einfüge.

Die Regeln, die die meisten Leute anwenden, sind

• Vor jedem Zeilenende
• Die Zeile endet jedoch mit einer }von einer Funktion kommenden Anweisung
• Aber nur eine Funktionsanweisung, keine Zuordnung zu einem Funktionsliteral

Meine Regel lautet: Am Anfang jeder einzelnen Zeile beginnt eine öffnende Klammer.

Meins ist einfacher, daher leichter zu verfolgen und weniger anfällig für Fehler. Auch die geringe Anzahl von Semikolons macht es leicht, Fehler zu finden, die durch Weglassen des Zeichens verursacht wurden.

Ein weiteres Argument ist, dass der berüchtigte return\nvalueBug darauf zurückzuführen ist, dass man nichts über ASI weiß. Meine Regel zwingt Sie, über ASI Bescheid zu wissen, sodass Personen, die meine Regel anwenden, mit geringerer Wahrscheinlichkeit in die Falle dieses Fehlers geraten.

Byteanzahl. Sie sehen, böswillige Menschen versuchen normalerweise, so viel in eine einzige Codezeile zu schreiben. Technisch 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 zu einer Anforderung als zu einem Vorschlag wird.