JavaScript的 5 個不良編碼習慣，如今就改掉吧！

翻譯：Jessie
原文連接：連接

每當閱讀 JavaScript 代碼的時候，你是否有如下感覺：

• 你幾乎不明白代碼的做用是什麼？
• 代碼使用了不少 JavaScript 技巧？
• 命名和代碼風格至關混亂？

上面這些就是典型的不良的編碼習慣。

在這篇文章裏，我會描述在 JavaScript 中 5 個常見 不良的編碼習慣，最重要的是我會推薦個人可行性建議來去擺脫託這些習慣。

1. 不要使用隱式類型轉換

JavaScript 是弱類型語言， 若是使用正確，這是一個好處，由於它給你提供了靈活性

大多數操做符+ - * / ==(但不是===)在處理不一樣類型的操做數時使用類型的隱式轉換

語法 if (condition) {...} while(condition) {...} 隱式的將條件轉換爲布爾值。

下面的例子依賴隱式類型轉換，我打賭你會感受到困惑：

console.log("2" + "1");  // => "21"
console.log("2" - "1");  // => 1

console.log('' == 0);    // => true

console.log(true == []); // -> false
console.log(true == ![]); // -> false
複製代碼

過度依賴隱式類型轉換是一種壞習慣， 首先，它讓你的代碼在邊界狀況下面不那麼穩定，其次，你增長了引入難以複製和修復的 bug 的機會。

咱們實現一個傳入對象類型參數的函數，若是屬性不存在，這個函數返回一個默認值：

function getProp(object, propertyName, defaultValue) {
  if (!object[propertyName]) {
    return defaultValue;
  }
  return object[propertyName];
}

const hero = {
  name: 'Batman',
  isVillian: false
};

console.log(getProp(hero, 'name', 'Unknown'));     // => 'Batman'
複製代碼

getProp 獲取 name 屬性的值是 Batman。

嘗試去訪問 isVillian 屬性會怎麼樣呢：

console.log(getProp(hero, 'isVillian', true)); // => true
複製代碼

這是個錯誤， 即便 hero 的 isVillian 屬性值是 false， getProp() 函數返回不正確的 true。

之因此會發生這種狀況，是由於屬性存在校驗依賴於 if (!object[propertyName]) {...} 隱式轉換爲布爾值。

這種類型的錯誤很難發現，去修復這個函數，須要明確驗證值的類型：

function getPropFixed(object, propertyName, defaultValue) {
   if (object[propertyName] === undefined) {
     return defaultValue;
   }
   return object[propertyName];
}

const hero = {
  name: 'Batman',
  isVillian: false
};

console.log(getPropFixed(hero, 'isVillian', true)); // => false
複製代碼

object[propertyName] === undefined 明確的驗證屬性訪問器是否爲 undefined。

你知道其餘方法去校驗屬性是否在對象裏面？若是是這樣，歡迎在下面留言！

邊注： 第四節建議避免直接使用 undefined。因此能夠用 in 操做符改進上述解決方案。

function getPropFixedBetter(object, propertyName, defaultValue) {
   if (!(propertyName in object)) {
     return defaultValue;
   }
   return object[propertyName];
}
複製代碼

下面是個人建議：只要有可能，不要使用隱式類型轉換。 相反，確認變量和函數參數始終擁有相同的類型。必要時使用顯式類型轉換。

最佳實踐列表：

• 始終使用嚴格相等操做符 === 進行比較
• 不要使用弱相等操做符 ==
• 加號操做符 operand1 + operand2: 兩邊的操做數應該是數值或者字符串類型
• 算數操做符 - * / % ** ：兩邊操做數應該是數值類型
• if (condition) {...}, while (condition) {...} 等語法：條件應該是布爾類型

你可能會說這種方法須要編寫更多的代碼...是的！可是使用顯式方法，你控制了你代碼的行爲。再者，顯式提升了可讀性。

2. 不要使用舊的 JavaScript 技巧

JavaScript 的有趣之處在於它的做者沒料到這種語言會如此流行。

基於 JavaScript 構建應用程序的複雜性比語言發展的速度還要快。這種狀況致使開發者使用 JavaScript 技巧和變通方法，只是爲了功能實現。

一個典型例子是查詢一個數組是否包含一個項，我歷來不喜歡使用 array.indexOf(item) !== -1 去驗證某一項是否存在。

ECMAScript 2015 及更高版本更強大，你可使用新語法特性來安全重構許多技巧。

重構 array.indexOf(item) !== -1 以支持新的 ES2015 方法 array.includes(item)。

按照 my compiled list of refactorings 去移除你 JavaScript 代碼中老的技巧。

3. 不要污染函數的做用域

在 ES2015 以前，JavaScript 變量是函數做用域的。所以，您可能養成了將全部變量聲明爲函數做用域的壞習慣。

咱們來看一個例子：

function someFunc(array) {
  var index, item, length = array.length;
  /*
   * Lots of code
   */
  for (index = 0; index < length; index++) {
    item = array[index];
    // Use `item`
  }
  return someResult;
}
複製代碼

變量 index item length 都是函數做用域，可是這些變量污染了函數做用域由於他們只是在 for() 代碼塊內使用。

根據塊級做用域變量 let 和 const 的介紹，你應該儘可能限制變量的生命週期。

讓咱們清理函數做用域：

function someFunc(array) {
  /*
   * Lots of code
   */
  const length = array.length;
  for (let index = 0; index < length; index++) {
    const item = array[index];
    // Use `item`
  }
  return someResult;
}
複製代碼

index 和 item 變量受限於 for() 循環塊範圍， length 被移到靠近使用的地方。

重構的代碼很容易明白由於變量不會分佈在整個函數做用域內。它們放在使用地點附近。

參數定義在使用的區塊範圍內：

if 塊範圍

// Bad
let message;
// ...
if (notFound) {
  message = 'Item not found';
  // Use `message`
}
複製代碼

// Good
if (notFound) {
  const message = 'Item not found';
  // Use `message`
}
複製代碼

for 塊範圍

// Bad
let item;
for (item of array) {
  // Use `item`
}
複製代碼

// Good
for (const item of array) {
  // Use `item`
}
複製代碼

4. 儘可能去避免 undefined 和 null

一個變量沒賦值會被計算爲 undefined。例如：

let count;
console.log(count); // => undefined

const hero = {
  name: 'Batman'
};
console.log(hero.city); // => undefined
複製代碼

count 變量被定義，可是沒有初始值，JavaScript 隱式賦值爲 undefined。

當訪問不存的屬性 hero.city，也是返回 undefined。

爲何直接使用 undefined 是個壞習慣？ 由於當你開始對比 undefined 時，你正在處理未初始化狀態的變量。

變量、對象屬性、數組在使用前必須有初始化的值！

JavaScript 提供了不少可能性來避免與 undefined 進行比較。

屬性是否存在

// Bad
const object = {
  prop: 'value'
};
if (object.nonExistingProp === undefined) {
  // ...
}
複製代碼

// Good
const object = {
  prop: 'value'
};
if ('nonExistingProp' in object) {
  // ...
}
複製代碼

對象的默認屬性

// Bad
function foo(options) {
  if (object.optionalProp1 === undefined) {
    object.optionalProp1 = 'Default value 1';
  }
  // ...
}
複製代碼

// Good
function foo(options) {
  const defaultProps = {
    optionalProp1: 'Default value 1'
  };
  options = {
    ...defaultProps,
    ...options
  };
  // ...
}
複製代碼

函數默認參數

// Bad
function foo(param1, param2) {
  if (param2 === undefined) {
    param2 = 'Some default value';
  }
  // ...
}
複製代碼

// Good
function foo(param1, param2 = 'Some default value') {
  // ...
}
複製代碼

null 是一個缺乏對象的指示符。

你應該努力去避免在函數中返回 null， 更重要的是，避免使用 null 參數去訪問函數。

只要 null 出如今你的調用堆棧中，你必須在每一個可能訪問 null的函數中檢驗它是否存在, 這會產生錯誤。

function bar(something) {
  if (something) {
    return foo({ value: 'Some value' });
  } else {
    return foo(null);
  }
}

function foo(options) {
  let value = null;
  if (options !== null) {
    value = options.value;
    // ...
  }
  return value;
}
複製代碼

嘗試去書寫沒有涉及 null 的代碼。可能的備選方案是 try/catch 機制，默認對象的用法。

ALGOL 的創造者 Tony Hoare ，曾經說過：

「我稱之爲十億美圓的錯誤...[...] 我正在設計第一個用於面嚮對象語言的引用的全面類型系統。[...]可是我沒法抗拒提出空引用的誘惑，很簡單由於它很容易實現。 這致使無數錯誤，漏洞和系統崩潰，在過去40年裏，這可能致使數十億美圓的痛苦和傷害。」

The worst mistake of computer science」 這篇文章深刻解釋了爲何 null 會對你的代碼質量形成傷害。

5. 不要使用隨意的代碼風格，執行一個標準

還有什麼比閱讀混亂的編碼風格更使人畏懼的呢？你永遠不知道會發生什麼！

假如代碼庫包含不一樣不少開發者不一樣的編碼風格會怎麼樣？各類各樣的字符塗鴉牆。

整個團隊和應用程序代碼庫中相同的編碼風格是必須的。 它提升了代碼的可讀性。

有用的編碼風格的示例：

• Airbnb JavaScript Style Guide
• Google JavaScript Style Guide

但說實話，我很懶。當我在截止日期前，或者在準備回家以前提交時，我可能就「忘記」了優化個人代碼。

「我本身很懶」的意思是：保持代碼不變，之後更新。可是之後意味着永遠不會。

我推薦自動化編碼風格驗證的過程：

• 安裝 eslint
• 配置適合你代碼風格的 eslint
• 設置預提交的 hook， 在提交以前運行 eslint 驗證

從 eslint-prettier-husky-boilerplate.開始。

6. 總結

書寫高質量、簡潔的的代碼須要自律，克服不良的編碼習慣。

JavaScript 是一個寬容的語言，有不少的靈活性。 可是你要注意你用的功能是什麼。 個人建議是避免隱式類型轉換並減小undefined 和 null的使用。

近期 JavaScript 發展十分迅速，識別複雜的代碼，而且使用最新的 JavaScript 特性去重構它。

貫穿代碼庫的一致的編碼風格有利於可讀性。

良好的編碼技一直是一個成功的解決方案。

你知道 JavaScript 中還有哪些很差的編碼習慣嗎？