現実の世界での自動タイプ変換

コアポイント

• JavaScriptの自動型変換は、さまざまな状況での利点であり、不利な点でもあります。コア関数として、オペレーターまたはステートメントが特定のデータ型を期待している場合、データを予想されるタイプに変換します。
• 変換結果によれば、JavaScript値は「True値」または「false値」と呼ばれます。 6つの誤った値があります：false、undefined、null、0、""、NaN（空の文字列）、
（非番号）。他のすべての値は真実と見なされます。
落とし穴を避けるために、型変換に評価にどのように影響するかを慎重に考慮する必要があります。たとえば、オプションのパラメーターのデフォルト値を定義する場合、故障を防ぐために既知のデータの真実を確保する必要があります。
• typeof
を使用した明示的なテストは常に安全ですが、自動タイプ変換を使用することはファイルサイズの考慮事項に有益です。ただし、プログラミング言語がタイプ変換を処理する方法を理解することは、予期しない結果を回避するために重要です。

JavaScriptで一般的な表現がいくつかありますが、プログラミングの純粋主義者の中には、決して良いアイデアではないことがわかります。これらの表現が共通しているのは、自動型変換に依存していることです。これは、JavaScriptのコア機能であり、状況と視点に応じて利点であり不利なものです。

この記事では、これらの2つの表現に特別な注意を払い、どのケースで良いアイデアであり、どちらが良いアイデアではないかを検討したいと思います。

if()最初の式は、単純な

条件です：

<code class="language-javascript">if (foo) {
}</code>

2番目の式は、オプションの値を持つ可変割り当てです：

<code class="language-javascript">var x = foo || bar;</code>

foo両方の例のbarとfooがブール値である場合、式は単純です。そうでないと、それ以外の場合はfooをfooに割り当てます。 x barしかし、それらが単純なブール値でない場合はどうなりますか？xがオブジェクト、文字列、または

である場合はどうなりますか？

とfooが異なるデータ型である場合はどうなりますか？これらの式がどのように計算されるかを理解するには、JavaScriptがデータ型間で自動的に変換する方法を理解する必要があります。 undefined foobar自動タイプ変換

javascriptは「ゆるく入力された」言語です。つまり、オペレーターまたはステートメントが特定のデータ型を期待するたびに、JavaScriptはデータを自動的にその型に変換します。最初の例のステートメントはブール値を期待するため、括弧内に定義されているものはすべてブール値に変換されます。同じことが

および

ステートメントにも当てはまります。 if()

このような変換の結果（つまり、真または偽）によれば、JavaScript値はしばしば「真」または「偽の値」と呼ばれます。それを理解する最も簡単な方法は、値が誤った値であることが知られていない限り、実際には6

（もちろん！）
• false
• undefined
• null
（number zero）
• 0
（空の文字列）
• ""
（番号以外）
• NaN
顕著な例外は、「0」（文字列ゼロ）とすべてのタイプのオブジェクトです - それらは真の値です - これには

すべての

ネイティブコンストラクターが含まれます。 （少し混乱しますが、実際には、そのようなネイティブの価値を作成する必要はありません。） new Boolean(false)注：2つのfalse値を比較すると、両方が誤った値であっても、（）など、予想される結果が常に生成されるとは限りません。平等評価がどのように機能するかを決定するかなり複雑なアルゴリズムがいくつかあり、それらを議論することはこの記事の範囲を超えています。ただし、詳細に興味がある場合は、ECMAScript 5.1の抽象的な平等比較アルゴリズムを確認できます。

null != false条件付きショートカット

例は、オブジェクトが常に真のように評価され、がfalsに評価されるため、その式をブール値に変換したことを示しました。要素の存在：

DOM仕様には存在しない要素が戻るif()を処理する必要があるため、これはDOM要素を処理するときに常に確実に機能します。 null

ただし、この例のように、他の状況はそれほど明確ではありません。

<code class="language-javascript">if (foo) {
}</code>

このような条件は、FOOパラメーターが定義されている場合、

"を示すためによく使用されますが、障害を引き起こす可能性のあるいくつかの状況があります。したがって、たとえば、それがブール値nullまたは空の文字列である場合、

が既に定義されている場合でも、条件付きコードは実行されません。

<code class="language-javascript">var x = foo || bar;</code>

私たちが望むのはこれです：

未定義のパラメーター（およびその他の変数）のデータ型は「foo」です。したがって、パラメーターのデータ型をテストするためにfalse比較器を使用して、fooが完全に定義されている場合、条件は常に通過します。もちろん、式は依然としてブール値を計算していますが、計算するブール値は式の結果です。

割り当てショートカット

<code class="language-javascript">var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}</code>

undefined最初に示した2番目の例では、論理演算子を使用して、2つの値のどれを変数に割り当てる必要があるかを判断します。 typeof foo論理演算子はif()ブール値を返しませんが、typeofブール値をまだ期待しているため、変換と計算は内部で発生します。 がtrueに評価された場合、の値は返されます。そうしないと、

値が返されます。これは非常に便利です。

この式は通常、イベントハンドラーで見られ、サポートされているモデルに基づいてイベントパラメーターを定義するために使用されます。

したがって、

<code class="language-javascript">if (foo) {
}</code>

は、ブール値として計算されます。これは、イベントパラメーターモデルがサポートされている場合（イベントオブジェクト）、それ以外の場合は誤った値（

）;それ以外の場合は、eを返します。 undefined 同じタイプの式の式もイベント属性を割り当てるためによく使用されます。各可能性を評価することにより、サポートされている属性を見つけます。 e したがって、これらの参照はそれぞれ（左から右へ）順番に評価され、最初の計算が返されます。最初のケースは標準モデルを処理します。2番目のケースはインターネットエクスプローラー用です。3番目のケースは、イベントがウィンドウオブジェクト（window.eventプロパティなし）でトリガーされる場合があるインターネットエクスプローラー用です。

しかし、この表現は、データの真実を知らずに、失敗する傾向があります。たとえば、別の一般的なユースケースは、オプションのパラメーターのデフォルト値を定義することですが、これは良くありません。

<code class="language-javascript">var x = foo || bar;</code>

さて、

srcElementが常に

または

であると確信している場合、空の文字列を

として扱う必要がある場合、式は安全です。しかし、そうでない場合は、より正確なコンテンツとして再定義する必要があります。

<code class="language-javascript">var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}</code>

「文字列」に対してタイプをテストすることにより、さまざまなケース（未定義のケース、および非ストリング値として誤って定義されている場合）を処理できます。この場合、空の文字列も有効な入力として許可しますが、空の文字列を除外する場合は、2番目の条件を追加する必要があります。

foo問題を引き起こす可能性のある驚くほど微妙な状況がいくつかあります。たとえば、入力タイムスタンプがオプションで定義されていない限り、UNIXタイムスタンプを作成する日付関数がある場合があります。 入力が0の場合、ゼロは誤った値であるため、失敗しますが、有効なタイムスタンプでもあります。 undefined undefined

一般原則

<code class="language-javascript">function doStuff(foo) {
  if (foo) {
    ...
  }
}</code>

fooこれらすべてから学んだ一般的なレッスンは簡単です。タイプの変換が評価にどのように影響するかを考えて、遭遇するトラップに陥らないように注意してください。適切な注意と注意を払えば、自動型変換を利用して、必要に応じて条件と論理式を短縮することができます。

しかし、これは疑問を提起します -

<code class="language-javascript">function doStuff(foo) {
  if (typeof foo != "undefined") {
    ...
  }
}</code>

を使用することが常に安全であることがわかっている場合、自動型変換に依存することは安全ではないことがあります - それでは

常に

常に明確ではありませんか？もちろん、より短い文法を好む理由がそれがより速くタイプするという理由だけである場合、これは怠zyでずさんな理由です。

<code class="language-javascript">var x = foo || bar;</code>

しかし、真実は、JavaScriptは通常、パブリックネットワーク上で実行されるということです。その場合、ファイルサイズが重要です。小さいファイルはロードが速く、帯域幅が少なくなり、小さな構文のショートカットが実際に蓄積する可能性があります。

より短い式を使用することは最適化そのものではなく、単なるプログラミングスタイルであり、言語機能を最大限に活用しています。

（元のテキストのFAQセクションは、この部分の内容が記事のトピックに弱く関連しており、より長いため、ここでは省略されているため、擬似オリジナル作品で保持するのに適していません。）

以上が現実の世界での自動タイプ変換の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。