如何編寫出優美的JavaScript代碼？

摘要：愛美之心，人皆有之。即使是一段普通的代碼，在保持思維清晰、功能友好的前提下怎樣編寫才能結構清晰、整潔美觀呢？

在多年以前，人們注重功能是如何?的。現如今，隨著Web及互連網技術的不斷髮展，功能僅成了最基本的要求，如何寫出漂亮，整潔的代碼已成為一個大牛級程式員不可或缺的條件。

一位前端開發工程師便在知乎上提問：“我是一名前端開發工程師，主要編寫JavaScript，有兩年經驗。最近在寫一些頁面上的模組，發現自己在構思的時候總是很清晰，但是寫著寫著感覺代碼越來越亂，看起來就像一坨屎，而我又有點兒代碼潔癖，看著越來越亂的代碼就不想進行下去。請問怎麼辦呢？”並且他還曬了一下自己編寫的JavaScript代碼：

面對如此樂知好學、積極進取的程式員，我們的網友們也很給力，不僅對他的代碼進行了全方位的點評，還提出了一些非常合理的建議，下面就是知乎網上一些網友的精彩回答，讓我們一起來看下：

長天之云：

我覺得寫好代碼和作文章差不多，無外乎：工整、優雅、拒絕重複、惜字如金。下面提供幾個小建議：

態度

對代碼要有感情，每一行都應該盡心儘力，並且還要有把那些扔垃圾簍的代碼再重寫兩遍的衝動——一旦有了這種衝動之後，什麼都擋不住你，連吃喝拉撒時，問題都會浮現到你腦子裡，你就會不由自主地解決它們……能對自己的代碼提出懷疑本身就是一件了不起的事！加油！

少寫代碼

提前設計能有助於少寫代碼，增強全域感。而代碼寫得少還能防止失控——感覺不對時就應該停下來，騰出時間來思考，為什麼會偏離最先的想法。所有符號各就各位。第一眼就是空格太少，下面推薦三個工具給大家：

1. Beautify JavaScript or HTML可以給你的代碼格式化，記得用diff工具對照一下，格式化前後的區別；
2. SublimeLinter可以動態地在編寫時給出JSHint提示（出錯行高亮）；
3. Grunt可以在檔案變更時給出SHint檢驗（聲音以及案頭通知）；

一旦把lint校正做為提交代碼的必要過程，排版就會有本質的提高。

遵行慣用法

1. 注釋符號‘//’後應該空一格；
2. 防止變數提升，應先聲明後使用（JSHint會提醒出‘_height’存在變數提升以及定義後未使用的錯誤）；
3. 不應該使用寫入程式碼，並且重複幾次（ID尾碼名可以定義到常量裡，用大寫字母）；
4. 不應該有兩個配置屬性，含義不明（this.opts和this._options）；
5. 若兩次以上引用同一對象的屬性，應該定義到局部變數再引用（var options = this._options）；
6. 不應該同時使用兩種屬性命名風格（colModel和table_body）；
7. 局部變數名應該儘可能短，而方法名應該儘可能完整（不應該同時即有fromatTpl又有parseTemplate）；
8. 局部變數名不需要用底線開頭，僅對象私人屬性和私人方法有此必要；
9. 變數名不需要帶類型屬性（_thdoms叫ths就好）；
10. 使用JavaScript時，for迴圈基本可以避免（比如jQuery有$.each, $.map，$.filter, $.grep等等高階函數可用）；
11. jQuery對象名習慣以$開頭，以便區分DOM對象；
12. jQuery查詢應盡量使用ontext（如 this.$table = $('table', this.$element) ）；
13. jQuery DOM操作和原生DOM操作不應該混用（已經使用jQuery的情況，就應該堅持使用jQuery來操作DOM，避免醜陋的原生操作）；
14. DOM元素構造出來，也不應該再到文檔中查詢一遍了（圖上的構造太複雜，一眼真看不懂）；

代碼複查

把程式寫正確還只是跨出了第一步。把代碼交給你的同事和朋友複查，這是學習經驗、共同提高 最快的辦法。

大石頭Dion：

代碼風格及排版

雖然任何一種語言都沒有任何約定的風格，但也總有一些不成文且喜聞樂見的習俗。以你的代碼為例，給以下幾個風格上的建議：

• 每個function之間多一空行，是的，除去注釋外再多一空行；
• 適當加空格，比如if和後面的括弧之間的空格、小括弧和花括弧之間的空格、冒號和function之間的空格等等；
• 風格上保持一致，你的代碼裡面有的地方+號和運算數之間有空格，有的則沒有；
• 少用底線開頭的變數命名；
• 一段代碼裡，var語句可以合并在一起；
• 暫時不會再修改的function或object，先用編輯器摺疊起來，看上去也會整潔很多；
• 黑色背景的Editor風格不錯，不過關鍵字、注釋、運算子等顏色上可以再調整，主要是為了防止審美疲勞，換個色調換個心情；

使用成熟的JavaScript庫

如果沒看錯的話，你可能是使用了jQuery吧（至少也有一個類似Sizzle或更簡單的解析器，證據在倒數第十行左右）。所以，就儘可能避免使用原生的JavaScript DOM操作。

jQuery的$符號，以CSS Selector風格統一取代了各種getElement(s)ByXxx的介面，並且擴充性非常強，是很多設計模式思想的綜合運用。

當然原生DOM也有自己的優勢（主要是執行效率），但是大部分時候，在開發效率、代碼品質、執行效率的tradeoff中，jQuery還是最佳選擇。此外也推薦下JavaScript MVC庫、jQuery UI庫等等。

代碼整理

構思清楚，再寫代碼，你已經做到了。

但是，誰能保證代碼是一成不變、一勞永逸的呢？

所以，「重構」的時候，除非是時間緊迫，永遠不要鬆懈代碼品質。

Web前端愛好者TooBug對樓主的代碼也進行了詳細的點評，並且也給出了一些非常有意義的指導：

1. 代碼中邏輯沒有分塊、沒有空行、沒有注釋、看起來很累，建議對代碼進行分塊，比如將變數集中在頭部定義，然後處理一些賦值，最後執行一些其它的函數。具體到這個例子，有很多不恰當的地方，比如可以先var _height；然後在條件分支中進行賦值，比如在一堆指派陳述式中間夾雜了一個parseTemplate。
2. “_”用得太多，this._var這個可以理解，因為要區分是否私人變數，但是var _height這個完全沒有必要加，加得太多反而看著很累，而且也沒有任何區分的意義。
3. 沒有將常用的變數緩衝，這裡最應該緩衝的是this._options，要不然看起來很亂，而且緩衝起來對效能也是有好處的。
4. 對象的規劃（命名）不清晰，比如this._options和this.opts什麼關係？我反正是看不明白。
5. 代碼風格不統一，比如訪問對象，之前都是this._options.height，為什麼後面出來一個this._options.data['head']？用this._options.data.head不是更清晰嗎？
6. 函數內變數名混亂（和第四點很像），比如第二個函數中id和_id什麼關係？為什麼不用aaaId和bbbId？cre又是什麼，難道是createElement縮寫？變數盡量起有意義的，可區分的名字。
7. 函數名稱表義不明，命名不符合大部分規範約定。第一眼看到_isHaveTable，我第一反應是，這應該是類似return true或者return false之類的吧。結果一看，這麼長，難道返回在後面？又往後看了一眼，這根本就沒有返回啊！那為什麼要用_isHaveTable啊？_is開頭的函數明明白白就應該返回一個true或者false啊。

以上是比較精彩的回答。保持適當的空格、風格統一、使用一些約定成俗的命名規則，比如局部變數名應該儘可能短，而方法名應該儘可能完整。

各位網友們，你們又有哪些妙招呢？不妨發來和我們一起探討探討吧！