Best Practices

快速列出撰寫 JavaScript 程式碼時應避免的事情。 避免使用 new Object() 來建立新物件，改用物件字面語法 {}。 陣列也一樣，優先使用 [] 而非 new Array()。 除了在 if、switch、迴圈、try 等語句需要的情況下，盡量避免使用區塊。 永遠不要在 if 或 while 語句的條件部分進行賦值。 永遠不要使用 == 和 !=，改用 === 和 !==。 永遠不要使用 eval。為什麼？它會導致效能問題（執行解譯器／編譯器）、安全問題（若與使用者輸入一起使用，可能會造成代碼注入）和調試困難。 永遠不要使用 with，因為它會修改作用域鏈並導致混淆。 總是將函式傳遞給 setTimeout 和 setInterval。 永遠不要將 Array 用作關聯陣列，改用 Object。提供該功能的部分實際上是由 Object 的原型提供的，所以你實際上可以使用 Date 物件來達到同樣的目的。 不要在字串的末尾使用 \ 來建立多行字串，這不是 ECMAScript 的一部分。改用字串串接 ' string1 ' + ' string2 ' 代替。 永遠不要修改內建物件 Object 和 Array 的原型。修改其他物件的原型（例如 Function）時要小心，因為這可能導致難以調試的錯誤。

這個 JavaScript 程式碼風格是我在使用 JavaScript 時每天都遵循的一套規範。這是一份不斷更新的文件，我遵循的主要規則。 每種語言都有一套語法規則。 剛開始時，有些人可能會按照不破壞語言規則的方式將代碼添加到文件中，但卻不關心和注意編程風格。 這並不是因為他們不關心風格，而是因為他們還沒有足夠的經驗來認識其重要性。 我真的相信編程是一門藝術。就像繪畫、木工或任何涉及創造力的事情一樣，我們的程序可以做很多事情，但它們應該以一種有風格的方式進行。 我們有一些適用於所有編程語言的規則。 編程風格是與您自己和團隊達成的一種共識，以保持項目的一致性。 如果您沒有團隊，則這是一份與自己的共識，始終保持您的代碼達到您的標準。 在代碼編寫格式上設定固定規則有助於使代碼更易讀且易於管理。 常用的風格指南 這裡有幾個常用的風格指南，以下是 JavaScript 領域中最常見的兩個： Google JavaScript Style Guide AirBnb JavaScript Style Guide 您可以選擇遵循其中之一，或者創建自己的風格指南。 始終與您所工作的項目保持一致 即使您偏好一套風格，但在項目中工作時，應該使用該項目的風格。 GitHub 上的開源項目可能遵循一套規則，您在團隊中的另一個項目可能遵循完全不同的規則。 Prettier 是一個很棒的工具，可以強制執行代碼格式，請使用它。 我的個人偏好 我對 JavaScript 風格的看法是： 始終使用最新的 ES 版本。如果需要支持舊瀏覽器，使用 Babel。 縮進：使用空格而不是制表符，縮進使用 2 個空格。 分號：不使用分號。 行長：盡量將行長限制在 80 個字符，如果可能的話。 行內注釋：在代碼中使用行內注釋。僅使用塊注釋進行文檔化。 無用代碼：不要註釋掉舊代碼，以防萬一將來會用到。僅保留您現在需要的代碼，版本控制/您的筆記應用程序是為此而設的。 僅在需要時進行注釋：不要添加不幫助理解代碼的注釋。如果代碼通過良好的變量和函數命名以及 JSDoc 函數注釋能夠自我解釋，則不需要添加注釋。 變量聲明：始終聲明變量以避免污染全局對象。不要使用 var。默認使用 const，僅在需要重新賦值變量時使用 let。 函數：除非有特殊原因需要使用常規函數（例如對象方法或構造函數），否則使用箭頭函數。將它們聲明為 const，如果可能的話使用隱式返回。 const test = (a, b) => a + b const another = a => a + 2 可以自由使用嵌套函數將幫助函數隱藏在代碼的其餘部分中。...

了解為什麼不應該修改 JavaScript 物件的原型，以及應該做什麼 作為程式設計師，我們必須首先學會的技能之一就是如何尋找解決方案。 Google 是你的朋友。而大多時候，一個來自 2009 年的 StackOverflow 解答能夠完美解決你在 2019+ 的問題。 在該網站或個人部落格上，有時候我會看到一些修改內建物件原型的程式碼。 就像這個例子，它擴充了 Array 物件的原型，增加了一個 insert 方法： Array.prototype.insert = function(index, item) { this.splice(index, 0, item) } 這樣一來，你可以對任何陣列調用 insert() 方法： ['red', 'blue'].insert(0, 'yellow') 這樣很方便。你不需要定義這樣的函式，也不需要擔心作用域的問題，只需將它附加到 Array 物件上，這樣每個陣列都可以使用它。 但僅僅因為你能這麼做，並不意味著你應該這樣做。 這種方法有什麼問題呢？ 可能的衝突 假設你使用的一個函式庫實現了這樣的功能。而你引入的另一個函式庫也做了同樣的事情。可能這些方法稍有不同，看起來好像一切都順利，直到事情不好時。 你會有一個大問題，因為你無法修改這些函式庫，但你仍然希望使用它們。 未來護航你的程式碼 假設下一個 JavaScript 版本實作了 Array.insert 方法，但參數簽名不同。現在會發生什麼？你需要回頭重寫所有的程式碼。也許是為了一個你不再工作的客戶。 或者你可能在一個被其他人在他們自己的專案中使用的函式庫中這樣做，那就更糟糕了。 這種做法只會造成技術債務，並且很容易引發問題。 你應該做什麼？ 在程式庫檔案中創建一個函式，需要時導入它。不要修改你無法控制的對象。