5個要矯正的JavaScript編程陋習

在閱讀JavaScript（JS）代碼時，您是否有過這樣的感受：
你幾乎徹底不明白這條代碼的做用？
這些代碼使用了大量的JS技巧？
命名和編程風格至關隨意？
這些是編程陋習的徵兆。

在這篇文章中，我將會概述JS中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。

大家有什麼其餘方法來驗證對象中的屬性是否存在嗎？若是有，請在下面的評論區留言！

邊注：在第4（此處須要一個超連接直接跳到第4部分）部分我有建議避免直接使用undefined。所以，上述解決方案能夠用運算符in進一步改進：

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

個人建議是:儘量不要使用隱式類型轉換。相反，請確保變量和函數參數始終具備相同的類型，必要時使用顯式類型轉換。

你們最好這麼作：

始終使用嚴格的相等運算符===進行比較

不要使用鬆散等式運算符==

加法運算符operand1 + operand2：兩個操做數應該是數字或字符串

算術運算符- / % *：兩個操做數都應該是數字

if (condition) {...}，while (condition) {...}等語句中的condition必須是一個布爾類型值

你們可能會以爲這種方式須要編寫更多代碼...的確！可是經過明確的方法，咱們可以控制代碼的行爲。此外，顯性類型轉換加強了可讀性。

2. 不要使用早期的JavaScript技巧
JS的有趣之處在於，它的建立者並無料到這種語言會如此流行。
基於JS構建的應用程序的複雜性比語言發展的速度還要快。這種狀況迫使開發人員使用JS技巧和變通方法，只是爲了讓事情正常運行。

一個典型的例子是查看數組是否包含某個元素。我從不會使用array.indexOf(item) !== -1來檢查。

ECMAScript 2015及之後版本的功能要強大得多，可使用新的語言特性安全地重構許多技巧。

在新的ES2015中可使用array.includes(item)來代替array.indexOf(item) !== -1。

你們能夠根據我寫的重構列表來清除你的JS代碼中的老舊技巧。

3. 不要污染函數做用域
在ES2015以前，JS變量在函數做用域內，所以你們可能會習慣了將全部變量聲明在函數做用域裏面。

咱們來看一個例子：

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變量已定義，但還沒有使用值初始化。JS隱式賦值給它undefined。

在咱們訪問不存在的屬性hero.city時，也會返回undefined。

爲何直接使用undefined是一個陋習呢？由於與undefined進行比較時，實際上咱們正在處理的是未初始化狀態的變量。

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

JS提供了不少避免與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曾說過：
「我把它稱爲個人十幾億美圓的錯誤…[…]我設計了第一個面嚮對象語言的綜合類型系統。[…]可是我沒法抗拒放入null引用的誘惑，由於它很容易實現。這致使了無數的錯誤、漏洞和系統崩潰，在過去四十年中，這些錯誤和崩潰可能形成了十億美圓的損失。」

「計算機科學中最糟糕的錯誤」一文深刻分析了爲何null會破壞代碼的質量。

5. 不要使用隨意的編碼風格，執行一個標準
有什麼比閱讀具備隨機編碼風格的代碼更使人生畏的事情？你永遠不知道會發生什麼！
若是代碼庫包含許多開發人員的不一樣編碼風格，該怎麼辦?，這種就像各色人物塗鴉牆。

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

一些有用的編碼風格的例子：
愛彼迎 JS 風格指南
谷歌 JS 風格指南
老實說，我很懶。當我正面臨着死線或者在回家前準備提交時，我可能會「忘記」設計代碼的樣式。

懶惰的我總對本身說：先這樣吧，之後再更新它，可是"之後"意味着永遠不會。
因此在這裏我建議使用 eslint 來規範編碼風格。
安裝eslint
使用最適合本身的編碼風格去配置eslint
設置一個預提交hook，在提交以前運行eslint驗證。

6. 總結
編寫高質量和乾淨的代碼須要有紀律性，咱們克服編碼陋習。
JS是一種自由的編程語言，具備很大的靈活性。可是咱們必須注意咱們所使用的特性。這裏個人建議是避免使用隱式類型轉換undefined和null。

如今這種編程語言發展得至關快。找出複雜的代碼，並使用最新的JS特性來重構簡化。
整個代碼庫的一致編碼風格有益於可讀性。
優秀的編程技能老是一個共贏的解決方案。

今天的分享就到這裏，但願本文能幫助到您！
看以後

點贊，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）
關注公衆號「新前端社區」，享受文章首發體驗！
每週重點攻克一個前端技術難點。