JavaScript程式碼規範！
原連結：segmentfault.com
1.為什麼要程式碼規範
軟體bug的修復是昂貴的，並且隨著時間的推移，這些bug的成本也會增加，尤其當這些bug潛伏並慢慢出現在已經發布的軟體中時。當你發現bug的時候就立即修復它是最好的，此時你程式碼要解決的問題在你腦中還是很清晰的。否則，你轉移到其他任務，忘了那個特定的程式碼，一段時間後再去檢視這些程式碼就需要：
花時間學習和理解這個問題
花時間是瞭解應該解決的問題程式碼
還有問題，特別對於大的專案或是公司，修復bug的這位夥計不是寫程式碼的那個人（且發現bug和修復bug的不是同一個人）。因此，必須降低理解程式碼花費的時間，無論是一段時間前你自己寫的程式碼還是團隊中的其他成員寫的程式碼。這關係到底線（營業收入）和開發人員的幸福，因為我們更應該去開發新的激動人心的事物而不是花幾小時幾天的時間去維護遺留程式碼。
另一個相關軟體開發生命的事實是，讀程式碼花費的時間要比寫來得多。有時候，當你專注並深入思考某個問題的時候，你可以坐下來，一個下午寫大量的程式碼。
你的程式碼很能很快就工作了，但是，隨著應用的成熟，還會有很多其他的事情發生，這就要求你的進行進行審查，修改，和調整。例如：
bug是暴露的
新功能被新增到應用程式
程式在新的環境下工作（例如，市場上出現新想瀏覽器）
程式碼改變用途
程式碼得完全從頭重新，或移植到另一個架構上或者甚至使用另一種語言
由於這些變化，很少人力數小時寫的程式碼最終演變成花數週來閱讀這些程式碼。這就是為什麼建立可維護的程式碼對應用程式的成功至關重要。
可維護的程式碼意味著：
可讀的
一致的
可預測的
看上去就像是同一個人寫的
已記錄
這裡還是要推薦下小編的web前端學習群:867726593，不管你是小白還是大牛，小編我都歡迎，不定期分享乾貨，包括小編自己整理的一份最新的web前端資料和0基礎入門教程，歡迎初學和進階中的小夥伴。在不忙的時間我會給大家解惑。
2.編寫程式碼需遵守的幾個原則
提示： 不遵守這些原則程式碼也能執行起來。只是可能出現難以維護的現象。規範就像一種模式，大家按照一種模式來，那麼閱讀其他人的程式碼，成本就降低了。
編寫程式碼注意事項：
2.1.儘量減少宣告全域性變數
2.2.定義變數是，儘量放到頂部
注意：在es6中，使用let定義，可能出現’暫時性死區’,具體想知道什麼叫做’暫時性死區’,請檢視阮一峰《ECMAScript6 》入門
2.3.for迴圈(forLoops)
JSLint提示您這樣做，原因是++和–-促進了“過分棘手(excessivetrickiness)”。//zxx:這裡比較難翻譯，我想本意應該是讓程式碼變得更加的棘手如果你直接無視它，JSLint的plusplus選項會是false（預設是default）。
還有兩種變化的形式，其又有了些微改進，因為：
少了一個變數(無max)
向下數到0，通常更快，因為和0做比較要比和陣列長度或是其他不是0的東西作比較更有效率
//第一種變化的形式：
vari, myarray = [];
for(i = myarray.length; i–-;) {
//使用myarray[i]做點什麼
}//第二種使用while迴圈：varmyarray = [],
i= myarray.length;
while(i–-) {
//使用myarray[i]做點什麼
}
面兩種情況優於前面兩種情況。
2.4.for-in迴圈(for-inLoops)
for-in迴圈應該用在非陣列物件的遍歷上，使用for-in進行迴圈也被稱為“列舉”。
從技術上將，你可以使用for-in迴圈陣列（因為JavaScript中陣列也是物件），但這是不推薦的。因為如果陣列物件已被自定義的功能增強，就可能發生邏輯錯誤。另外，在for-in中，屬性列表的順序（序列）是不能保證的。所以最好陣列使用正常的for迴圈，物件使用for-in迴圈。
有個很重要的hasOwnProperty()方法，當遍歷物件屬性的時候可以過濾掉從原型鏈上下來的屬性
2.5.（不）擴充套件內建原型((Not)Augmenting Built-in Prototypes)
增加內建的建構函式原型（如Object(),Array(),或Function()）挺誘人的，但是這嚴重降低了可維護性，因為它讓你的程式碼變得難以預測。使用你程式碼的其他開發人員很可能更期望使用內建的JavaScript方法來持續不斷地工作，而不是你另加的方法。
因此，不增加內建原型是最好的。你可以指定一個規則，僅當下面的條件均滿足時例外：
可以預期將來的ECMAScript版本或是JavaScript實現將一直將此功能當作內建方法來實現。例如，-你可以新增ECMAScript5中描述的方法，一直到各個瀏覽器都迎頭趕上。這種情況下，你只是提前定義了有用的方法。
如果您檢查您的自定義屬性或方法已不存在——也許已經在程式碼的其他地方實現或已經是你支援的瀏覽器JavaScript引擎部分。
你清楚地文件記錄並和團隊交流了變化。
一般情況下，強烈不建議使用
2.6.避免隱式型別轉換(AvoidingImplied Typecasting )
JavaScript的變數在比較的時候會隱式型別轉換。這就是為什麼一些諸如：false== 0 或“” ==0 返回的結果是true。為避免引起混亂的隱含型別轉換，在你比較值和表示式型別的時候始終使用===和!==操作符。
2.7.避免(Avoiding)eval()
如果你現在的程式碼中使用了eval()，記住該咒語“eval()是魔鬼”。此方法接受任意的字串，並當作JavaScript程式碼來處理。當有問題的程式碼是事先知道的（不是執行時確定的），沒有理由使用eval()。如果程式碼是在執行時動態生成，有一個更好的方式不使用eval而達到同樣的目標。例如，用方括號表示法來訪問動態屬性會更好更簡單：
3.編碼規範
3.1縮排(Indentation)
程式碼沒有縮排基本上就不能讀了。唯一糟糕的事情就是不一致的縮排，因為它看上去像是遵循了規範，但是可能一路上伴隨著混亂和驚奇。重要的是規範地使用縮排。
一些開發人員更喜歡用tab製表符縮排，因為任何人都可以調整他們的編輯器以自己喜歡的空格數來顯示Tab。有些人喜歡空格——通常四個，這都無所謂，只要團隊每個人都遵循同一個規範就好了。這本書，例如， 使用四個空格縮排，這也是JSLint中預設的縮排。
什麼應該縮排呢？規則很簡單——花括號裡面的東西。這就意味著函式體，迴圈(do,while, for, for-in)，if，switch，以及物件字面量中的物件屬性。下面的程式碼就是使用縮排的示例：
3.2花括號{}(CurlyBraces)
//糟糕的例項for(vari =0;i <10;i +=1)
alert(i);//好的例項for(vari =0;i <10;i +=1){
alert(i);}
3.3左花括號的位置(OpeningBrace Location)
這個例項中，仁者見仁智者見智，但也有個案，括號位置不同會有不同的行為表現。這是因為分號插入機制(semicoloninsertionmechanism)——JavaScript是不挑剔的，當你選擇不使用分號結束一行程式碼時JavaScript會自己幫你補上。這種行為可能會導致麻煩，如當你返回物件字面量，而左括號卻在下一行的時候
3.4空格(WhiteSpace)
空格的使用同樣有助於改善程式碼的可讀性和一致性。在寫英文句子的時候，在逗號和句號後面會使用間隔。在JavaScript中，你可以按照同樣的邏輯在列表模樣表示式（相當於逗號）和結束語句（相對於完成了“想法”）後面新增間隔。
適合使用空格的地方包括：
for迴圈分號分開後的的部分：如for(var i = 0; i < 10; i += 1) {…}
for迴圈中初始化的多變數(i和max)：for(var i = 0, max = 10; i < max; i += 1) {…}
分隔陣列項的逗號的後面：vara = [1, 2, 3];
物件屬性逗號的後面以及分隔屬性名和屬性值的冒號的後面：varo = {a: 1, b: 2};
限定函式引數：myFunc(a,b, c)
函式宣告的花括號的前面：functionmyFunc() {}
匿名函式表示式function的後面：varmyFunc = function () {};
使用空格分開所有的操作符和操作物件是另一個不錯的使用，這意味著在+,-, *, =, <, >, <=, >=, ===, !==, &&, ||,+=等前後都需要空格。
最後需要注意的一個空格——花括號間距。最好使用空格：
函式、if-else語句、迴圈、物件字面量的左花括號的前面({)
else或while之間的右花括號(})//{}空格
if(4) {
console.log(1)
}else if (3) {
console.log(1)
}
vara = {}
4.命名規範
另一種方法讓你的程式碼更具可預測性和可維護性是採用命名規範。這就意味著你需要用同一種形式給你的變數和函式命名。
下面是建議的一些命名規範，你可以原樣採用，也可以根據自己的喜好作調整。同樣，遵循規範要比規範是什麼更重要。
4.1以大寫字母寫建構函式(CapitalizingConstructors)
JavaScript並沒有類，但有new呼叫的建構函式：
因為建構函式仍僅僅是函式，僅看函式名就可以幫助告訴你這應該是一個建構函式還是一個正常的函式。命名建構函式時首字母大寫具有暗示作用，使用小寫命名的函式和方法不應該使用new呼叫：
4.2分隔單詞(SeparatingWords)
當你的變數或是函式名有多個單詞的時候，最好單詞的分離遵循統一的規範，有一個常見的做法被稱作“駝峰(Camel)命名法”，就是單詞小寫，每個單詞的首字母大寫。
對於建構函式，可以使用大駝峰式命名法(uppercamel case)，如MyConstructor()。
對於函式和方法名稱，你可以使用小駝峰式命名法(lowercamel case)，像是myFunction(),calculateArea()和getFirstName()。
4.3註釋(WritingComments)
你必須註釋你的程式碼，即使不會有其他人向你一樣接觸它。通常，當你深入研究一個問題，你會很清楚的知道這個程式碼是幹嘛用的，但是，當你一週之後再回來看的時候，想必也要耗掉不少腦細胞去搞明白到底怎麼工作的。
很顯然，註釋不能走極端：每個單獨變數或是單獨一行。但是，你通常應該記錄所有的函式，它們的引數和返回值，或是任何不尋常的技術和方法。要想到註釋可以給你程式碼未來的閱讀者以諸多提示；閱讀者需要的是（不要讀太多的東西）僅註釋和函式屬性名來理解你的程式碼。例如，當你有五六行程式執行特定的任務，如果你提供了一行程式碼目的以及為什麼在這裡的描述的話，閱讀者就可以直接跳過這段細節。沒有硬性規定註釋程式碼比，程式碼的某些部分（如正則表示式）可能註釋要比程式碼多。
5.css程式碼規範
css規範我們偉大的張鑫旭老師，講的很清楚。《面向屬性的命名》
這是比較好的命名規範。簡介來說，就是我們先定義好一些常用基礎類樣式。元件則使用less,或者sass進行組裝，形成即可。