技術者以外の人から見れば、プログラマーの間で意見が分かれ続けているタブ対スペースの議論の不条理さを覆そうとする試みと受け止められるかもしれないが、JavaScript が実装されている仕様である ECMAScript の開発を助言する TC39 技術グループは、Web 開発者にステートメントと宣言をセミコロンで終了するように指示することを提案した。
セミコロンは、JavaScript ステートメントを互いに区切るのに役立ちます。
すでに多くの JavaScript 開発者がコードにセミコロンを散りばめていますが、ECMAScript 仕様ではほとんどの場合にセミコロンが必須であるにもかかわらず、そうする必要がほとんどありません。
それは、抜け道があるからです。「ただし、便宜上、特定の状況では、このようなセミコロンをソーステキストから省略することができます」とECMAScriptの仕様では説明されています。
ECMAScript では、ほとんどの場合、自動セミコロン挿入 (ASI) と呼ばれるメカニズムを通じてプログラマが句読点の要件を無視できます。ASI は、その名前が示すように、ソース ファイルが JavaScript エンジンによって解析されるときに、コード構造の終わりを示すセミコロン トークンを自動的に追加します。
これは、文字を追加するたびにエラーが発生する可能性が高まることを認識しているプログラマーにとって、厳格な基準に縛られないことのメリットです。これは、ジャストインタイムのスペルチェッカーに似ています。
さらに、この自由放任主義のアプローチにより、JavaScript はかなり寛容になり、その結果、経験の浅いプログラマーにとってより魅力的なものになります。
リーナス・トーバルズ、カーネルコメントの句読点について暴言を吐く
続きを読む
しかし、JavaScriptのクラスフィールドを定義する場合など、セミコロンを省略するとASIメカニズムが混乱し、エラーや予期しない結果が発生する場合があります。そのため、セミコロンの使用を推奨することで、セミコロンを省略できない特殊なケースを認識する必要性が軽減されます。
ASI の利点に関する議論は長年にわたって続いていますが、ソース コードをタブとスペースのどちらでインデントするべきかという長年解決されていない論争と同様に、依然として意見の相違が残っています。
JavaScript の生みの親であるブレンダン・アイク氏は、コードの正確性を強化する他の手段があり、リスクのある文法の追加を避けることのほうがより良いアプローチであると述べ、Twitter で反対の意を表明した。
この提案が採用されたとしても、直ちに大きな影響はないでしょう。JavaScript開発者は依然としてこの勧告を無視し、セミコロンを省略することができます。ASIは依然として不足している記号を検出し、追加します。リンターと呼ばれる他の構文チェックツールも同様の機能を果たすでしょう。
「誤解のないよう申し上げますが、ASI を廃止したり削除したりするつもりはありません」と、スペインのコンサルタント会社 Igalia のシステム ソフトウェア エンジニアであり、Google の Linux カーネル チームの元メンバーでもある Daniel Ehrenberg 氏はThe Registerへの電子メールで述べています。
提案の共著者の一人である Ehrenberg 氏は、この勧告が ECMAScript の複雑化によって将来生じる問題を回避する手段であると考えています。
提案された文言には、「ECMAScript に新しい構文機能が追加されるにつれて、明示的なセミコロンを必要とするケースが時間の経過とともに増えていきます。そのため、一貫して明示的なセミコロンの使用が推奨されます。」と記載されています。
ここでの意図は、ASI が信頼できない状況があり、ECMAScript が進化するにつれてそのような状況が増える可能性が高いため、ASI への依存を推奨しないことです。
とはいえ、ECMAScript標準としてまだ承認されていないこの提案には、批判者もいる。この提案に関するGitHubのコメント（プルリクエスト）で、ベルリンを拠点とする開発者Yoshua Wuyts氏は、「少し悲しくなりました。私が書く言語はJSだけで、セミコロンも使いません。これは単なる警告条項だとは分かっていますが、TC39が、私たちが特定の方法でこの言語を使うのは良くないと言っているように聞こえます。そして、それは、まあ、少し傷つきます。」と嘆いている。®
