ホームページ > 記事 > ウェブフロントエンド > js関数と感嘆符の関係
関数の前に感嘆符 (!) を追加するとどうなりますか?
たとえば、次のコード:!function(){alert('iifksp')}() // trueコンソールで実行した後に得られる値は true ですが、この 私たちは、匿名関数を呼び出すためにかっこを追加することに慣れているかもしれません:
(function(){alert('iifksp')})() // trueまたは:
(function(){alert('iifksp')}()) // true上記のかっこの位置は異なりますが、効果はまったく同じです。 それでは、多くの人がこの感嘆符の方法を好む理由は何でしょうか? 1 文字を保存するだけであれば、100K のライブラリでもあまりスペースを節約できない可能性があります。スペースではないため、時間の考慮事項がある可能性があることを意味します。事実は記事の最後に記載されています。 核心的な質問に戻りますが、なぜこれができるのでしょうか?さらに中心的な疑問は、なぜこれが必要なのかということです。 実際、括弧であろうと感嘆符であろうと、ステートメント全体で合法的に実行できることは 1 つだけです。それは、関数宣言ステートメントを
式 に変換することです。 function a(){alert('iifksp')} // undefined
これは関数宣言です。そのような宣言の後に括弧を追加して直接呼び出すと、当然パーサーはそれを理解できず、エラーを報告します:
function a(){alert('iifksp')}() // SyntaxError: unexpected_token
そのようなコードはこのように関数宣言と関数呼び出しを混同するためです。宣言された関数 a は a(); として呼び出す必要があります。
ただし、括弧は異なります。パーサーは関数宣言を関数宣言としてではなく、
関数式として処理するため、プログラムの実行時にのみ処理できます。関数 a が存在する場合にのみアクセスできます。 つまり、
関数宣言と関数式を明確にするメソッドはすべて、パーサーによって正しく認識されます。例: var i = function(){return 10}(); // undefined
1 && function(){return true}(); // true
1, function(){alert('iifksp')}(); // undefined
代入、ロジック、さらにはカンマ、さまざまな
は、これが関数宣言ではなく、関数式であることをパーサーに伝えることができます。さらに、関数に対する単項演算は、曖昧さを排除するための最も早い方法であると考えることができます。戻り値を気にしない場合、これらの単項演算は有効です。
!function(){alert('iifksp')}() // true +function(){alert('iifksp')}() // NaN -function(){alert('iifksp')}() // NaN ~function(){alert('iifksp')}() // -1キーワードを使用できます 素晴らしい仕事です:
void function(){alert('iifksp')}() // undefined new function(){alert('iifksp')}() // Object delete function(){alert('iifksp')}() // true最後に、括弧も同じことを行います。曖昧さの解消がその本当の仕事であり、関数全体を囲むことではありません。そのため、括弧で宣言が囲まれているか、関数全体が囲まれているかは、すべてです。法的:
(function(){alert('iifksp')})() // undefined (function(){alert('iifksp')}()) // undefinedここまで述べてきましたが、実際、私が話しているのは最も基本的な概念の一部です - ステートメント、式、式ステートメント これらの概念は、ポインターやポインター変数と同じくらい混乱を引き起こしやすいものです。この種の混乱はプログラミングに表現的な影響を与えませんが、それが原因でいつでも頭を壊す可能性があるつまずきの石です。 最後にパフォーマンスについて説明します。私は単純に jsperf でテストを作成しました:
http://jsperf.com/js-funcion-expression-speed
。これは、さまざまなブラウザーでアクセスし、テストを実行して結果を表示できます。結果も以下の表に示しました(私は比較的下手なので、テスト構成は少し恥ずかしいですが、仕方がない:Pentiumデュアルコア1.4G、2Gメモリ、win7 Enterprise Edition):さまざまな方法で生成されていることがわかります。結果は同一ではなく、ブラウザごとに大きく異なります。
しかし、それらの間にはまだ多くの共通点を見つけることができます:新しい方法は常に最も遅い
- これは当然のことです。他の側面の多くの違いは実際には大きな違いではありませんが、1 つ確かなことは、感嘆符は最も理想的な選択ではないということです。一方、伝統的な括弧は、テストでは常に非常に高速に実行され、ほとんどの場合、感嘆符よりも高速です。したがって、私たちが通常使用する方法に問題はなく、最適であるとさえ言えます。 プラス記号とマイナス記号は Chrome で驚くほどパフォーマンスが良く、他のブラウザでも一般に高速で、感嘆符よりもうまく機能します。 もちろん、これは単なる簡単なテストであり、問題を説明することはできません。しかし、いくつかの結論は理にかなっています。つまり、括弧とプラス記号とマイナス記号が最適であるということです。 しかし、なぜこれほど多くの開発者が感嘆符を好むのでしょうか?これは単なる習慣の問題であり、両者の有利不利は完全に無視してよいと思います。コーディング スタイルに慣れると、この規則によりプログラムがわかりにくいものから読みやすいものに変わります。感嘆符に慣れてしまえば、括弧よりも感嘆符の方が読みやすいことは認めざるを得ません。読むときに括弧の対応に注意を払う必要がなく、書くときにうっかり忘れる必要もありません -
以上がjs関数と感嘆符の関係の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。