現實世界中的自動類型轉換

核心要點

• JavaScript 的自動類型轉換在不同情況下既是優勢也是劣勢。作為核心功能，它會在運算符或語句期望特定數據類型時將數據轉換為預期類型。
• 根據轉換結果，JavaScript 值被稱為“真值”或“假值”。共有六個假值：false、undefined、null、0、""（空字符串）和 NaN（非數字）。所有其他值都被視為真值。
• 必須仔細考慮類型轉換如何影響評估以避免陷阱。例如，在為可選參數定義默認值時，必須確保已知數據的真值性以防止失敗。
• 雖然使用 typeof 進行顯式測試始終安全，但使用自動類型轉換有利於文件大小的考慮，因為較小的文件加載速度更快且帶寬使用更少。但是，理解編程語言如何處理類型轉換對於避免意外結果至關重要。

JavaScript 中有一些表達式很常見，但一些編程純粹主義者會告訴你它們從來都不是好主意。這些表達式的共同點是它們依賴於自動類型轉換——JavaScript 的核心功能，根據情況和你的觀點，它既是優勢也是劣勢。

因此，在本文中，我想特別關注這兩個表達式，並考慮它們在哪些情況下是好主意，哪些情況下不是好主意。

第一個表達式是一個簡單的 if() 條件：

if (foo) {
}

第二個表達式是一個帶有可選值的變量賦值：

var x = foo || bar;

如果這兩個例子中的foo 和bar 都是布爾值，那麼表達式很簡單：如果foo 為真，則第一個條件通過；如果foo 為真，則第二個表達式將foo 賦值給x，否則將bar 賦值給x。

但是，如果它們不是簡單的布爾值——如果 foo 是一個對象、一個字符串或 undefined 怎麼辦？如果 foo 和 bar 是不同的數據類型怎麼辦？要理解這些表達式將如何計算，我們需要了解 JavaScript 如何在數據類型之間自動轉換。

自動類型轉換

JavaScript 是一種“鬆散類型”語言，這意味著每當運算符或語句期望特定數據類型時，JavaScript 都會自動將數據轉換為該類型。第一個例子中的 if() 語句期望一個布爾值，因此括號中定義的任何內容都將轉換為布爾值。 while() 和 do...while() 語句也是如此。

根據此類轉換的結果（即真或假），JavaScript 值通常被稱為“真值”或“假值”。最簡單的理解方法是這樣的：除非已知值為假值，否則該值為真值；實際上，只有 六個 假值：

• false（當然！）
• undefined
• null
• 0（數字零）
• ""（空字符串）
• NaN（非數字）

值得注意的例外是“0”（字符串零）和所有類型的對象——它們是真值——這包括所有 原生構造函數，這意味著new Boolean(false) 計算結果為真！ （有點令人困惑，但在實踐中你永遠不需要那樣創建原生值。）

注意：比較兩個假值並不總是會產生你可能期望的結果，例如（null != false），即使兩者都是假值。有一些相當複雜的算法決定了相等性評估的工作方式，討論它們超出了本文的範圍。但如果你對細節感興趣，可以查看 ECMAScript 5.1 中的抽象相等比較算法。

條件快捷方式

我在開頭向你展示的if() 示例將其表達式轉換為布爾值，由於對象總是計算為真而null 計算為假，因此我們可以使用這樣的條件來測試DOM 元素的存在：

if (foo) {
}

在處理 DOM 元素時，這始終可靠地工作，因為 DOM 規範要求不存在的元素返回 null。

但是，其他情況並非如此明確，例如這個例子：

var x = foo || bar;

這樣的條件經常用於表示 “如果 foo 參數已定義”，但是有幾種情況會導致失敗——即 foo 是假值的情況。因此，例如，如果它是布爾值 false 或空字符串，則不會執行條件代碼，即使 foo 已 定義。

我們想要的是這個：

var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}

未定義的參數（和其他變量）的數據類型為“undefined”。因此，我們可以使用 typeof 比較器來測試參數的數據類型，然後如果 foo 完全定義，則條件將始終通過。當然，if() 表達式仍在計算布爾值，但它計算的布爾值是該 typeof 表達式的 結果。

賦值快捷方式

我在開頭向你展示的第二個示例使用邏輯運算符來確定應將兩個值中的哪個值賦給變量：

function doStuff(foo) {
  if (foo) {
    ...
  }
}

邏輯運算符不 返回 布爾值，但它們確實仍然 期望 布爾值，因此轉換和計算會在內部發生。如果 foo 計算結果為真，則返回 foo 的 值，否則返回 bar 的值。這非常有用。

這個表達式通常在事件處理函數中看到，它用於根據支持的模型定義事件參數：

if (foo) {
}

因此，e 計算為布爾值，如果支持事件參數模型，則該布爾值為真值（事件對象），否則為假值（undefined）；如果它是真值，則返回e，否則返回window.event。

同樣類型的表達式也常用於分配事件屬性，通過評估每個可能性來查找支持的屬性：

var x = foo || bar;

因此，這些引用中的每一個都依次（從左到右）進行評估，並且第一個計算結果為真的將被返回。第一種情況處理標準模型，第二種情況用於 Internet Explorer，而第三種情況用於 Internet Explorer，當事件可能在窗口對象（沒有 srcElement 屬性）上觸發時。

但是，這種表達式同樣容易失敗，在不知道數據真值性的情況下。例如，另一個常見的用例是為可選參數定義默認值，但這不好：

var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}

現在，如果你確定 foo 總是 是字符串或 undefined，並且假設空字符串應被視為 undefined，那麼該表達式是安全的。但如果不是，則需要將其重新定義為更精確的內容，例如：

function doStuff(foo) {
  if (foo) {
    ...
  }
}

通過針對“字符串”測試類型，我們可以處理多種情況——foo 未定義的情況，以及將其錯誤定義為非字符串值的情況。在這種情況下，我們還允許空字符串作為有效輸入，但如果我們想排除空字符串，則必須添加第二個條件：

function doStuff(foo) {
  if (typeof foo != "undefined") {
    ...
  }
}

還有其他一些令人驚訝的微妙情況可能會導致問題。例如，我們可能有一個日期函數，它創建 unix 時間戳，除非可選地定義輸入時間戳：

var x = foo || bar;

如果輸入為 0，則會失敗——因為零是假值，但它也是有效的時間戳。

一般原則

從所有這些中吸取的一般教訓很簡單——考慮類型轉換將如何影響評估，並註意不要陷入我們遇到的陷阱。經過適當的注意和關注，你仍然可以利用自動類型轉換，在適當的情況下縮短條件和邏輯表達式。

但這確實提出了一個問題——如果我們知道使用 typeof 進行顯式測試始終安全，而依賴自動類型轉換有時並不安全——那麼為什麼不 始終 明確呢？當然，如果偏好較短語法的原因僅僅是因為它鍵入速度更快，那麼這是一個懶惰和草率的原因。

但事實是，JavaScript 通常通過公共網絡運行，在這種情況下文件大小很重要。較小的文件加載速度更快，並且帶寬使用更少，小的語法快捷方式確實可以累積。

利用較短的表達式本身並不是一種優化，它只是一種編程風格，它充分利用了語言特性。

(此處省略了原文中的常見問題解答部分，因為該部分內容與文章主題關聯性較弱，並且篇幅較長，不適合在偽原創中保留。)

以上是現實世界中的自動類型轉換的詳細內容。更多資訊請關注PHP中文網其他相關文章！