最近、JavaScriptからセミコロンを削除/省略するようになったのはなぜですか？
最近、Javascriptからセミコロンを省略することが流行しているようです。 ブログ投稿 が数年前にJavascriptで強調されていた セミコロンはオプション であり、投稿の要旨は、それらを気にしないでください。不要です。広く引用されている投稿は、それらを使用する説得力のある理由を使用しないわけではなく、それらを除外することにはほとんど副作用がありません。
GitHubがジャンプした セミコロンのないバンドワゴンで、内部で開発されたコードでは省略が必要であり、メンテナによるzepto.jsプロジェクトへの 最近のコミット は削除されましたコードベースのすべてのセミコロン。彼の主な正当化は：
- それは彼のチームの好みの問題です。
- タイピングが少ない
それらを省略する理由は他にありますか？
率直に言って、それらを省略する理由はなく、コードを削除してそれらを消去する理由は確かにありません。また、（ 年 ） 推奨される実行 にも反します。では、なぜ最近のセミコロン嫌いなのか。不足が迫っていますか？それとも、これは最新のJavascript流行ですか？
私の理由は最もラメだと思います：私は同時に多すぎる言語（Java、Javascript、PHP）でプログラムします-これには ';'が必要です私の指と目を訓練するのではなく、「;」 JavaScriptには必要ありません。常に「;」を追加するだけです。
もう1つの理由はドキュメントです。「;」を追加する私は、声明の終了が予想される場所を明確に述べています。次に、私も常に{}を使用します。
私がイライラして無意味であると思う全体のバイト数の引数：
1）jqueryのような一般的なライブラリの場合：google CDNを使用すると、ライブラリはおそらくブラウザーのキャッシュに既に存在します
2）独自のライブラリをバージョン管理し、それらを永久にキャッシュするように設定します。
3）本当に必要な場合は、gzipして最小化します。
しかし、実際には最大の速度として、javascriptのダウンロード速度のボトルネックとなっているサイトはいくつありますか。 Twitter、google、yahooなどのトップ100サイトで働いている場合は、私たちの残りは、セミコロンの宗教戦争ではなく、コードの品質を心配するだけです。
メソッドの連鎖を容易にし、差分をより明確にコミットします
だから私が約jQueryしていて、私が持っているとしましょう
$('some fancy selector')
.addClass()
.attr();
ものを追加したい場合そして、行ベースのコミット差分を小さくしておくの場合は、attrの上に追加する必要があります。したがって、単に「最後に追加」するよりも長い考えです。そして、誰が考えたいですか？ =）
$('some fancy selector')
.addClass()
// new method calls must go here
.attr();
しかし、セミコロンをドロップすると、1日追加して1日と呼ぶことができます。
$('some fancy selector')
.addClass()
.attr()
+ .animate()
+ .click()
また、最後のメソッドをポップすることにした場合、セミコロンを再度割り当ててコミットを汚染する必要はありません。
$('some fancy selector')
.addClass()
.attr()
.animate()
- .click()
対ウゴ
$('some fancy selector')
.addClass()
.attr()
+ .animate();
- .animate()
- .click();
セミコロンを使わない私の個人的な理由はOCDです。
セミコロンを使用すると、2％を忘れて、常にチェック/追加する必要があります。
セミコロンを使用しない場合は、誤って1つ入れてしまうことがないため、セミコロンをチェック/削除する必要はありません。
情報の過負荷などはなく、デザインが悪いだけです。
—エドワード・タフテ
不要な要素や装飾を省いてノイズを減らすのは グラフィックデザインの一般的なルール です。
画面上の視覚要素が少ないほど、脳が実際の有用な情報を解析するための作業が少なくなります。
let foo = 1
vs.
let /* variable */ foo = 1; // EOL
もちろん誇張された例ですが、それは一般的な原則を示しています。追加の視覚要素は、目的を果たす場合にのみ追加する必要があります。では、セミコロンは目的を果たしますか？
JavaScriptでセミコロンを使用する歴史的な理由は次のとおりです。
- C/Javaとの類似性を維持する
- 不十分に記述されたブラウザーおよびツールとの互換性の問題を回避する
- 人と機械がコードエラーを検出するのを助ける
- セミコロンの自動挿入は パフォーマンスペナルティ を伴います
現在、互換性の問題はほとんど問題になりません。最近のリンターはコードエラーを検出できます 同様に セミコロンなし。 C/Java/PHPとの類似性も考慮に入れることができます（Patによる 受け入れられた回答 を参照）。ただし、他の言語に余分な構文要素が含まれているからといって、JavaScriptでそれらを保持する必要があるとは限りません。他の言語（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のパーサー/アナライザーを作成しました。ASIを入念に実装する必要がありました。また、CrockfordのJavaScript：The Good Partsのコピーもalwaysを推奨する本棚。セミコロンを使用します。意図は良かったが、実際には必ずしも役立つとは限らない。
明らかに、jQuery、zeptoなどのフレームワークを記述している人々はJavaScript構文のマスターであるため、次の違いを知っています。
return
{
status: true
};
そして
return {
status: true
};
JavaScriptは強力ですが、初心者の言語でもあり、forループについて理解している人に説明できれば幸いです。ほとんどの人に新しいスキルを紹介するのと同じように、すぐに説明したくない複雑なことがいくつかあります。そのため、特定のことに「カーゴカルト」の信念を浸透させることを選択します。したがって、JavaScriptの書き方を初心者に教える場合、2つの選択肢があります。
- 「この1つのルールに従い、理由は尋ねない」と伝え、すべての行の最後にalwaysセミコロンを付けるように伝えます。残念ながら、これは上記の例や、ASIが邪魔する他の例では役に立ちません。そして、上記のコードが失敗すると、初心者または初心者のプログラマーは困惑します。
- 「これらの2つのルールに従い、理由を尋ねない」と伝え、すべての行の終わりにセミコロンを付けないようにして、代わりにalways a）
returnに{を続け、b ）行が(で始まる場合は、その前に;を追加します。
オプション2を選択することは、従うべき「カーゴカルト」ルールのより良いセットであり（ASI関連のバグは非常に少なくなります）、トピックを深く理解しても、画面上の不要な文字は少なくなります。
プログラミング規則の選択は、ターゲット言語のサブセットを選択することと実質的に同じです。コードの可読性、保守性、安定性、移植性などの通常の理由で、これはすべて行われますが、柔軟性を犠牲にする可能性があります。これらの理由は、実際のビジネス上の理由です。
「キーストロークを保存する」や「プログラマーがJavaScriptのルールを学ぶ必要がある」などの理由は、ビジネス上の理由としてはあまり重要ではないため、実用的な重みはほとんどありません。
私の場合、JavaScriptで非常に速く処理する必要があったので、言語の限られたサブセットを活用することが私の利点でした。そこで、JavaScriptのJSLintサブセットを選択し、EclipseでRockstarアプリのJSLinterを、私が我慢できる最も制限的な設定に切り替え、振り返っていませんでした。
「==」と「===」の違いの詳細、またはセミコロン挿入の詳細を回避できることに感謝しています。これは、1マイルのタスクリストがすでにあり、それらの詳細は表示されないためです。これらの仕事を1秒早く完了させるのに役立ちます。
もちろん、規約について最も重要なことは一貫性であり、言語のサブセットとしてそれを考えることはこの命令を強化するのに役立ちます。そして、これはOPの質問に答える助けにはならないかもしれませんが、それはそれの実際的なフレーミングに役立つかもしれないと思います。
かなり古い質問ですが、誰も言及していないことに驚いています。
Minification：ステートメントをセミコロン文字で明示的に終了しないJavaScriptスニペットをたまたま縮小すると、スニペットの何が問題かを理解するのに苦労する可能性がありますそれは縮小の前に機能していましたが、現在は機能しません。
Ambiguity：セミコロンはオプションですが、trueですが、ソースコードからセミコロンを削除することにより、パーサーにいくつかのあいまいなシナリオを残して独自に決定することができます。オンラインショップ用に100行のコードを記述している場合、はい、おそらくそれは問題ではありませんが、より深刻なタスクでは100％の明快さが必要になります。
ずっと前に私は何か他のものについて非常に素晴らしいアナロジーを読みましたが、それはこの場合にも非常に当てはまります：（私たちの場合）セミコロンを排除することは赤い光で交差するようなものです。最終的には大丈夫かもしれないし、トラックにひかれるかもしれない。
なぜ最近人気が高まっているのですか？
JavaScriptをサーバー側で実行することは、JavaScriptコミュニティ自体に多くの影響を与えたと個人的に考えています。私たちの場合、サーバー側でJavaScriptを縮小するつもりはないので（ソースコードはクライアントのWebブラウザーに出荷されることは想定されていないため）、セミコロンがない方がはるかに安全に見えます。しかし、これらの本、記事、ビデオから学ぶ他の開発者たちは、残念ながらサーバーサイドのJavaScriptがクライアントサイドのJavaScriptとまったく同じではないという事実を否定しています。
それらを保持する十分な理由があります。
それらは実際にはオプションではありません、JSはそれらが欠落しているときに自動セミコロン挿入でそれらを戻すことができますが、それは同じことではありません。
Douglas CrockfordのJavaScript：Good Partsは、2つの別々の機会に、それが悪いアイデアだと言っています。セミコロンの自動挿入により、プログラム内のバグが非表示になり、あいまいさが生じる可能性があります。
JSLintは承認しません。
JavaScriptでは、10年以上ステートメントを終了するためにセミコロンは必要ありませんでした。これは、改行文字がステートメントターミネーターと見なされるためです（これは、初期のECMAScript仕様でも言及されていると思います）。 JavaScriptがセミコロンを頻繁に使用する必要があるが、RubyまたはPython。
セミコロンを必要とすることで、言語のパーサーを簡単に作成できるようになりますが、everyインタプリタがセミコロンの省略をサポートしている場合、正確には何がポイントですか？
プログラマーの知識がどれほど重要であるかは次のとおりです。セミコロンを省略できることがわかっている場合は、結果があるかどうかわからないので、遠慮なくそうしてください。人間は意思決定の機械であり、ほとんどすべての決定にはある程度の妥協やトレードオフが必要です。コードの周りにセミコロンを置くだけの場合のトレードオフは（必要のない場所でも）、コードが読みにくくなり（質問する相手によって異なります）、JSLintが文句を言わない（気にする人） ）。一方、セミコロンを省略した場合のトレードオフは、JavaScriptプログラマーの90％がそれを非難するだろうという事実ですが、それが原因でJavaScriptをもっと楽しんでしまうかもしれません。
何があなたに良く聞こえるか;情報に基づいた意思決定、または盲目的な意思決定/群れの考え方
私には2つの理論があります。
A）
この選択の重要な点は、JSLintなどが適用可能だった当時は、不明瞭な構文エラーをキャッチするために長い時間を費やすか、コードに標準ポリシーを適用するために妥当な時間を費やすことを選択していたということです。
ただし、 nit Test -Drivenコードと継続的インテグレーションに移行するにつれて、構文エラーを検出するために必要な時間（および人間の操作）が大幅に減少しました。テストからのフィードバックは、コードが期待どおりに機能しているかどうか、エンドユーザーに近づくかなり前にすぐにわかるので、なぜオプションの冗長性を追加するのに時間を浪費するのですか？
B）
怠惰なプログラマーは、短期的に自分の生活を楽にするために何でもします。タイピングが少ない->労力が少ない->簡単です。 （また、セミコロンを付ける必要がないことで、右の薬指に負担がかかり、RSInessがある程度回避されます）。
（注： 曖昧さをなくす ステートメントを省略するという考えには同意しません）。
省略はしませんが、挿入する際のルールを変更します。
ほとんどの人が使用するルールは
- 各行が終わる前
- 行が関数ステートメントからの
}で終わっていることを除いて - ただし、関数リテラルへの割り当てではなく、関数ステートメントのみ
私のルールは次のとおりです。左中かっこで始まるすべての行の先頭。
鉱山は単純なので、追跡が容易で、バグが発生しにくくなります。また、セミコロンの数が少ないため、省略して作成されたバグを簡単に見つけることができます。
もう1つの議論は、悪名高いreturn\nvalueバグはASIについて知らないことに起因するというものです。私のルールでは、ASIについて知っておく必要があるため、私のルールを使用している人は、そのバグの罠に陥る可能性が低くなります。
バイト数。ご存知のように、悪意のある人々は通常、1行のコードに多くを収めようとします。技術的に言えば、これはセミコロンなしでは不可能です。私の推測では、これは単なるプログラム上の要件というよりは、セキュリティ対策です。どういうわけか、これは提案ではなく要件になると、XSSを大幅に削減します。