Javascriptからセミコロンを削除/削除する最近のシフトはなぜですか？

Javascriptからセミコロンを省略することは最近流行しているようです。数年前、Javascriptではセミコロンはオプションであり、投稿の要点は不要であるため気にしないほうがよいと強調したブログ投稿がありました。広く引用されているこの投稿では、それらを使用しないという説得力のある理由は示されていません。ただ、それらを除外しても副作用はほとんどありません。

GitHubでさえ、セミコロンなしの時流に飛びついて、内部で開発されたコードを省略する必要があり、メンテナーによるzepto.jsプロジェクトへの最近のコミットにより、すべてのセミコロンがコードベースから削除されました。彼の主な理由は次のとおりです。

• 彼のチームの好みの問題です。
• タイピングが少ない

それらを除外する他の正当な理由はありますか？

率直に言って、私はそれらを省略する理由は見当たらず、それらを消去するためにコードに戻る理由は確かにありません。また、（年の）推奨されるプラクティスに反します。これは、「カーゴカルト」の議論を実際に購入するものではありません。では、なぜ最近のセミコロン嫌いなのでしょうか？迫り来る不足はありますか？または、これは最新のJavascriptの流行ですか？

私の理由は最も遅いと思います：私は同時に多くの異なる言語（Java、Javascript、PHP）でプログラムします-';'が必要です 指と目を訓練するのではなく、「;」javascriptには必要ありません。常に ';'を追加するだけです

もう1つの理由はドキュメントです。「;」を追加することにより 私は、声明の終わりをどこに期待するかを明確に述べています。それから再び{}を常に使用します。

バイトカウント引数全体は、私が刺激的で無意味だと思います：

1）jqueryのような一般的なライブラリの場合：Google CDNを使用すると、ライブラリはおそらくブラウザのキャッシュに既にある

2）独自のライブラリをバージョン管理し、それらが永久にキャッシュされるように設定します。

3）本当に必要な場合は、gzipして最小化します。

しかし、実際には、JavaScriptのダウンロード速度が最大の速度のボトルネックになっているサイトはいくつありますか？twitter、google、yahooなどのようなトップ100サイトで働いているなら。残りの人々は、セミコロンの宗教戦争ではなく、コードの品質について心配するだけです。

メソッドの連鎖を簡単にし、差分をより明確にコミットします

だから私はjQueryingだと言ってみましょう

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

何かを追加して、行ベースのコミットdiffを小さくしたい場合は、attrの上に追加する必要があります。そのため、「最後に追加する」よりも長く考えられます。そして、誰が考えたいですか？=）

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

しかし、セミコロンをドロップすると、1日だけ追加して呼び出すことができます

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

また、最後のメソッドをポップアウトすることに決めた場合、セミコロンを再割り当てしてコミットを再度汚染する必要はありません。

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

対uggo

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

JavaScriptのセミコロンはオプションです

セミコロンを使用しない私の個人的な理由はOCDです。

セミコロンを使用すると、それらの2％を忘れてしまい、それらを常にチェック/追加する必要があります。

セミコロンを使用しない場合、誤ってセミコロンを挿入することはないため、セミコロンをチェック/削除する必要はありません。

私は最近、私はASIを実装苦心しなければならなかったのJavaScript用のパーサ/アナライザを書いた、と私はまた、クロックフォードの私のコピー持ってJavaScriptを：良い部品を提唱し、私の本棚、上で常にセミコロンを使用します。意図は良かったのですが、実際に常に役立つとは限りません。

明らかに、jQuery、zeptoなどのフレームワークを記述する人々はJavaScript構文のマスターであり、したがって、彼らは次の違いを知っています。

return
{
    status: true
};

そして

return {
    status: true
};

JavaScriptは強力ですが、初心者向けの言語でもあり、forループとは何かを学んでいる人にこれを説明するのは幸運です。ほとんどの人に新しいスキルを紹介するように、すぐに説明したくないもっと複雑なものがあるので、代わりに特定の事柄に「貨物カルト」の信念を植え付けることを選択します。したがって、JavaScriptの作成方法を初心者に教える場合、次の2つの選択肢があります。

1. 「この1つのルールに従い、理由を聞かないでください」と伝え、すべての行の最後に常にセミコロンを入れるように伝えます。残念ながら、これは上記の例や、ASIが邪魔になる他の例では役に立ちません。また、初心者のプログラマーは、上記のコードが失敗すると混乱します。
2. 「これら二つのルールに従うと、なぜ質問しない」すべての行の末尾にセミコロンを気にし、代わりにしないようにそれらを伝える、それらを教え、常に a）に従っreturnて{、およびb）の行で始まる場合は(、先頭に追加それで;。

オプション2を選択することは、従うべき「カーゴカルト」ルールのより良いセットであり（ASI関連のバグはほとんど発生しません）、トピックを深く理解しても、画面上の不要な文字が少なくなります。

情報の過負荷などはなく、デザインが悪いだけです。

—エドワード・タフテ

それはだ、グラフィックデザインの一般的なルールのノイズを低減するために、不必要な要素と装飾を残します。

画面上の視覚要素が少ないほど、脳が実際の有用な情報を解析するための作業が少なくなります。

let foo = 1

対

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

もちろん誇張された例ですが、一般的な原則を示しています。目的に役立つ場合にのみ、視覚要素を追加する必要があります。それで、セミコロンは目的を果たしますか？

JavaScriptでセミコロンを使用する歴史的な理由は次のとおりです。

• C / Javaとの類似性を維持する
• 不十分な記述のブラウザとツールとの互換性の問題を回避する
• 人間と機械がコードエラーを検出できるようにする
• 自動セミコロン挿入はパフォーマンスの低下をもたらします

互換性の問題は、今日ではほとんど問題ではありません。現代リンターは、任意のコードのエラーを検出することができますちょうど同様にセミコロンなし。C / Java / PHPとの類似性は依然として考慮できますが（Pat の受け入れられた答えを参照）、他の言語に余分な構文要素が含まれているからといって、特に他の多くの言語（Coffeescript、Python、 Ruby、Scala、Lua）はそれらを必要としません。

V8でパフォーマンスが低下するかどうかを確認するために、簡単なテストを行いました。これは、セミコロンを使用して41 MBのJavaScriptファイル（Lodashを100回繰り返して）を解析し、セミコロンを削除したIo.jsです。

$ 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

誰もが自分のプロジェクトに適したコーディングスタイルを決定する必要がありますが、セミコロンを使用することによる具体的なメリットは見当たらないため、視覚的なノイズを減らすために停止しました。

プログラミング規則を選択することは、ターゲット言語のサブセットを選択することと事実上同じです。これは通常、コードの可読性、保守性、安定性、移植性などの理由で行われますが、柔軟性を犠牲にする可能性があります。これらの理由は、実際のビジネス上の理由です。

「キーストロークを節約する」、「プログラマーがJavaScriptルールを学習する必要がある」などの理由は、ビジネス上のわずかな理由であるため、実用的な重みはほとんどありません。

私の場合、JavaScriptの速度を非常に速くする必要があったため、言語の限られたサブセットを活用することが有利でした。そこで、私はJavaScriptのJSLintサブセットを選択し、EclipseのRockstarアプリJSLinterを、私が耐えられる最も制限の厳しい設定に切り替えました。

「==」と「===」の違いの詳細、またはセミコロン挿入の詳細を回避できることに感謝しています。なぜなら、1マイルの高さのタスクリストがすでにあり、それらの詳細はこれらのジョブを1秒早く完了させるのに役立ちます。

もちろん、規則について最も重要なことは一貫性であり、それを言語のサブセットとして考えることは、この必須事項を強化するのに役立ちます。そして、これはOPの質問に答える助けにはならないかもしれませんが、私はそれがその実用的な枠組みに役立つかもしれないと思う。

かなり古い質問ですが、誰も言及していないことに驚いています。

ミニフィケーション：明示的にセミコロン文字でステートメントを終了しないJavaScriptスニペットをミニファイする場合、ミニフィケーションの前に機能していたスニペットの何が問題なのかを理解するのに苦労する可能性がありますそして今は動作しません。

曖昧さ：セミコロンはオプションであり、本当ですが、ソースコードからセミコロンを削除することにより、曖昧なシナリオをパーサーに任せて独自に決定することができます。オンラインショップ用に100行のコードを記述している場合、はい、それは問題ではないかもしれませんが、より深刻なタスクには100％の明確さが必要です。

昔、私は何か他のことについて非常に良い類推を読みましたが、この場合も非常に真実です。最終的には大丈夫かもしれませんし、トラックにぶつかるかもしれません。

なぜ最近人気が出ているのですか？

私は個人的に、JavaScriptをサーバー側で実行するとJavaScriptコミュニティ自体に多くの影響を与えたと考えています。私たちの場合、サーバー側でJavaScriptを縮小する人は誰もいないのは明らかです（ソースコードはクライアントのWebブラウザーに出荷されることは想定されていないため）。しかし、これらの本、記事、ビデオから学ぶ他の開発者は、残念ながらサーバー側のJavaScriptがクライアント側のJavaScriptとまったく同じではないという事実を無視しています。

それらを保持する正当な理由があります。

それらは実際にはオプションではありません。JSは、欠落しているときに自動セミコロン挿入でそれらを再び追加できますが、それは同じではありません。

Douglas CrockfordのJavaScript：Good Partsは、2つの別々の場面で、それは悪い考えだと言っています。自動セミコロン挿入は、プログラムのバグを隠すことができ、あいまいさを生み出します。

JSLintは承認しません。

JavaScriptは、10年以上にわたってステートメントを終了するためにセミコロンを必要としませんでした。これは、改行文字がステートメントターミネータと見なされるためです（これは初期のECMAScript仕様でも言及されていると思います）。JavaScriptがセミコロンを頻繁に使用する必要があり、RubyやPythonのような他の解釈された宣言型言語を必要としない理由は本当にないので、それは本当に理にかなっています。

セミコロンが必要なため、言語のパーサーを記述しやすくなる場合がありますが、すべてのインタープリターがセミコロンの省略をサポートしている場合、正確なポイントは何ですか？

プログラマーがどれだけ知識があるかということです。セミコロンを省略できることを知っている場合は、結果があるかもしれないし、ないかもしれないということを理解して自由にそうしてください。人間は意思決定マシンであり、ほとんどすべての決定には妥協またはトレードオフが必要です。コードの周りにセミコロンを投げるだけで（トレードオフが必要な場所であっても）、トレードオフは（あなたが尋ねる人によっては）コードが読みにくくなり、JSLintが文句を言わないことです）。一方、セミコロンを省略することのトレードオフは、JavaScriptプログラマーの90％があなたを非難するという事実ですが、そのためにJavaScriptの作成を楽しんでしまう可能性があります。

あなたにとってより良い音。十分な情報に基づいた意思決定または盲目的な意思決定/群れメンタリティ

私には2つの理論があります。

A）

この選択に関することは、JSLintなどが適用されていた時代にさかのぼって、あいまいな構文エラーの検出にかなりの時間を費やすか、コードに標準ポリシーを適用するのに妥当な時間を費やすことでした。

ただし、単体テスト駆動型コードと継続的統合に向かって進むにつれて、構文エラーをキャッチするのに必要な時間（および人間の対話）は大幅に減少しました。テストからのフィードバックは、コードがエンドユーザーに近づくかなり前に、コードが期待どおりに動作しているかどうかをすばやく示します。

B）

怠け者のプログラマーは、短期的に自分の生活を楽にするために何でもします。タイピングが少ない->労力が少ない->簡単。（また、セミコロンを使用しなくても、右手の薬指に負担をかけずに、RSIを回避できます）。

（注意：ステートメントを明確にする何かを省略するという考えには同意しません）。

私はそれらを除外しませんが、それらを挿入するときのルールを変更します。

ほとんどの人が使用するルールは

• 各行が終了する前
• 行が}関数ステートメントから来ることを除いて
• ただし、関数リテラルへの割り当てではなく、関数ステートメントのみ

私のルールは次のとおりです。すべての単一行の先頭で、開き中かっこで始まります。

私のほうがよりシンプルであるため、追跡が容易であり、バグが発生しにくい。また、セミコロンの数が少ないため、除外することで作成されたバグを簡単に見つけることができます。

もう1つの議論は、悪名高いreturn\nvalueバグはASIを知らないことに起因するということです。私の規則では、ASIについて知る必要があるので、私の規則を使用している人は、そのバグに陥る可能性が低くなります。

バイト数。ご存知のように、悪意のある人は通常、1行のコードに多くを詰め込もうとします。技術的に言えば、これはセミコロンなしでは不可能です。私の推測では、それは単なるプログラム上の要件というよりも、セキュリティ対策であるということです。どういうわけか、これは提案ではなく要件になったときにXSSを大幅に削減します。