問題タブ [automatic-semicolon-insertion]

さて、最初に私はおそらくこれがブラウザに依存しているかどうかを尋ねるべきです。

無効なトークンが見つかったが、その無効なトークンまでコードのセクションが有効である場合、改行が前にある場合は、トークンの前にセミコロンが挿入されることを読みました。

ただし、セミコロンの挿入によって引き起こされるバグについて引用される一般的な例は次のとおりです。

.. _aは有効なトークンであるため、このルールには従わないようです。

一方、コールチェーンの分割は期待どおりに機能します。

誰かがルールのより詳細な説明を持っていますか？

Goもそれらを挿入すると聞いたが、彼らは別のアプローチに従った

Javascriptは、解釈中にセミコロンをどのように挿入しますか？

JavaScriptをJSHintでリントしていて、このオプションを有効にしています

コード内のセミコロンを避けるため。

ただし、新しい行はブラケットで開始する必要があるため、その行を開く前にセミコロンを配置する必要があります

JSHintは私に2つのエラーを与えます：

• ';'の後にスペースがありません
• ';'の後にスペースを入れると 私が得る：期待される'（'は異なるインデントを持っている

このようにJSHintが幸せであることに気づきました

しかし、私は良い解決策ではないと思います。

JSHintまたはホワイトオプションをオフにせずに、この問題を解決する方法はありますか？

Visual Studio 2012、Resharper 7.0.1 を使用

JavaScript を編集していて、次のように入力するとします (| = カーソル位置):

.. Resharper は私のために右中括弧を追加します:

...しかし、後でセミコロンも追加したい:

ご存じかもしれませんが、ECMAscript は賢くしようとし、セミコロンを明示的に記述していない場合は自動的にセミコロンを挿入します。簡単な例

引き続き期待どおりに動作します。ただし、これに頼る場合は注意点があります。その関数をそのように書き直すと

..その関数はundefined、インタープリターがステートメントの直後にそのセミコロンを挿入するため、返されるようになりましたreturn(これが、常にステートメントと同じ行に中括弧を配置する必要がある理由です)。

ただし、これらすべてを知っていると、次のようなステートメントがブラウザーやバージョン間でどれほど安全か疑問に思っていますreturn

return statement本番環境で同様のことを書きました。ECMAscript がセミコロンの挿入についてあまり賢くないという「問題」を知っていたからといって、そのコードが 100% 機能するかどうか疑問に思っています。FF/Chrome/IE (最新バージョン) での最初のテストでは、これはまったく問題ないように見えますが、本当にそうなのでしょうか?

その行にステートメント以外の何かがある場合、自動セミコロン挿入は「ウェイクアップ」しますか? returnこれについて実装レベルの詳細を提供できる人はいますか?

必要な場所にセミコロンを自動的に挿入する JavaScript プリプロセッサを作成しています。理由を聞かないでください。

この問題に取り組む一般的な方法は、JavaScript パーサーを作成し、仕様の規則に従って必要に応じてセミコロンを追加することであることがわかりました。ただし、次の理由により、そうしたくありません。

1. 私は本格的なパーサーを書きたくありません。
2. コメントと空白を保持したい。

簡単なスキャナーを使用して、自動セミコロン挿入の 2 番目と 3 番目のルールを既に (正しく) 実装しています。

ただし、最初のルールは、実装がより困難であることがわかります。だから私は3つの質問があります：

1. 先読みと後読みを備えた単純なスキャナーを使用して最初のルールを実装することは可能ですか?
2. それが可能なら、誰かがすでにそれを行っていますか?
3. そうでない場合、どうすればこの問題に取り組むことができますか?

完全を期すために、ここに 3 つのルールを示します。

• プログラムが左から右に解析されるときに、文法のどの生成でも許可されていないトークン (問題のあるトークンと呼ばれる) が検出された場合、次の 1 つ以上の場合、問題のあるトークンの前にセミコロンが自動的に挿入されます。条件は真です:

  1. 問題のあるトークンは、少なくとも 1 つのLineTerminatorによって前のトークンから分離されています。

  2. 問題のあるトークンは}です。

• プログラムが左から右に解析されるときに、トークンの入力ストリームの終わりが検出され、パーサーが入力トークン ストリームを単一の完全な ECMAScript Programとして解析できない場合、セミコロンが末尾に自動的に挿入されます。入力ストリーム。

• プログラムが左から右に解析されるときに、文法の一部の生成によって許可されているトークンが検出されたが、生成が制限された生成であり、トークンが注釈の直後の終端または非終端の最初のトークンになる場合"[no LineTerminator here]" 制限されたプロダクション内 (したがって、そのようなトークンは制限されたトークンと呼ばれます) であり、制限されたトークンは少なくとも 1 つのLineTerminatorによって前のトークンから分離され、制限されたトークンの前にセミコロンが自動的に挿入されます。 .

ただし、前述のルールには追加のオーバーライド条件があります。セミコロンが空のステートメントとして解析される場合、またはそのセミコロンがforステートメントのヘッダーにある 2 つのセミコロンの 1 つになる場合、セミコロンは自動的に挿入されません(セクション12.6.3 )。

今日、このコードが原因で非常に驚きました

明らかに、ここでは JavaScript の「自動セミコロン挿入」が期待どおりに機能していません。しかし、なぜ？

そのようなことを避けるためにどこでも使用することをお勧めするかもしれません;が、問題は使用する方が良いかどうかではあり;ません。ここで正確に何が起こっているのか知りたいですか？

JS の自動セミコロン挿入for(...)は、次の例で配置したように末尾にセミコロンを配置しますか、それとも for ループでブラケットを新しい行に分割しても安全ですか?

何が影響を受けているかを示す多くの情報を見つけましたが、私の質問に固有のものは何もないため、影響を受けていない可能性があると思われますが、具体的な答えを見つけたいと思います.

個人的には、このような括弧で改行したくないのですが、疑問が生じました;)

多数の変数を null に設定したい (そして配列/ループ構造を使用したくない) と言うか、単に複数行にわたって大きなブール式を書きたいだけだとします。このような場合、閉じていない括弧はセミコロンの挿入を防ぎますか? 例えば

または

また、改行を介して式をグループ化する&&orを使用する||場合と比較して、これはどうですか? =つまり、これも常に機能しますか？

すべてのブラウザー (IE6+ を含む) で最も標準的な方法を探しています。

セミコロンを忘れると C++ などの言語は機能しませんが、JavaScript などの他の言語では自動的に含まれます。

私はこの記事から知っています JavaScript のすべてのステートメントの後にセミコロンを使用することをお勧めしますか? 、セミコロンを使用することが推奨されており、不要なあいまいさを作成する可能性のあるシナリオがあります (ブレースが使用されていない場合に C++ で他にぶら下がっているなど)。

ある時点で、それらをオプションにする決定があったに違いありません (たとえば、JavaScript の作成者がそれをオプションにするという意識的な選択をしたとき)。

この決定が下された理由と、これらの言語のユーザーにとってどのように役立つかを知りたい.

背景: 私は初心者のコーダーで、最近 JavaScript の学習を始めたばかりです。

編集：JavaScriptでは悪いと言っているコメントに、私は知っています。ほとんどの人がそれを悪い習慣だと考えるのであれば、そもそもなぜそれが許されているのかと私は尋ねています。