南寧達內(nèi)：如何編寫出優(yōu)美的代碼？

在多年以前，人們注重功能是如何實現(xiàn)的。現(xiàn)如今，隨著Web及互聯(lián)網(wǎng)技術的不斷發(fā)展，功能僅成了最基本的要求，如何寫出漂亮，整潔的代碼已成為一個大牛級程序員不可或缺的條件。

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

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

長天之云：

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

態(tài)度

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

少寫代碼

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

BeautifyorHTML可以給你的代碼格式化，記得用diff工具對照一下，格式化前后的區(qū)別；

SublimeLinter可以動態(tài)地在編寫時給出JSHint提示（出錯行高亮）；

Grunt可以在文件變更時給出SHint檢驗（聲音以及桌面通知）；

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

遵行慣用法

注釋符號‘//’后應該空一格；

防止變量提升，應先聲明后使用（JSHint會提醒出‘_height’存在變量提升以及定義后未使用的錯誤）；

不應該使用硬編碼，并且重復幾次（ID后綴名可以定義到常量里，用大寫字母）；

不應該有兩個配置屬性，含義不明（this.opts和this._options）；

若兩次以上引用同一對象的屬性，應該定義到局部變量再引用（varoptions=this._options）；

不應該同時使用兩種屬性命名風格（colModel和table_body）；

局部變量名應該盡可能短，而方法名應該盡可能完整（不應該同時即有fromatTpl又有parseTemplate）；

局部變量名不需要用下劃線開頭，僅對象私有屬性和私有方法有此必要；

變量名不需要帶類型屬性（_thdoms叫ths就好）；

使用時，for循環(huán)基本可以避免（比如jQuery有$.each,$.map，$.filter,$.grep等等高階函數(shù)可用）；

jQuery對象名習慣以$開頭，以便區(qū)分DOM對象；

jQuery查詢應盡量使用ontext（如this.$table=$('table',this.$element)）；

jQueryDOM操作和原生DOM操作不應該混用（已經(jīng)使用jQuery的情況，就應該堅持使用jQuery來操作DOM，避免丑陋的原生操作）；

DOM元素構(gòu)造出來，也不應該再到文檔中查詢一遍了（圖上的構(gòu)造太復雜，一眼真看不懂）；

代碼復查

把程序?qū)懻_還只是跨出了第一步。把代碼交給你的同事和朋友復查，這是學習經(jīng)驗、共同提高最快的辦法。

大石頭Dion：

代碼風格及排版

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

每個function之間多一空行，是的，除去注釋外再多一空行；

適當加空格，比如if和后面的括號之間的空格、小括號和花括號之間的空格、冒號和function之間的空格等等；

風格上保持一致，你的代碼里面有的地方+號和運算數(shù)之間有空格，有的則沒有；

少用下劃線開頭的變量命名；

一段代碼里，var語句可以合并在一起；

暫時不會再修改的function或object，先用編輯器折疊起來，看上去也會整潔很多；

黑色背景的Editor風格不錯，不過關鍵字、注釋、運算符等顏色上可以再調(diào)整，主要是為了防止審美疲勞，換個色調(diào)換個心情；

使用成熟的庫

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

jQuery的$符號，以CSSSelector風格統(tǒng)一取代了各種getElement(s)ByXxx的接口，并且擴展性非常強，是很多設計模式思想的綜合運用。

當然原生DOM也有自己的優(yōu)勢（主要是執(zhí)行效率），但是大部分時候，在開發(fā)效率、代碼質(zhì)量、執(zhí)行效率的tradeoff中，jQuery還是最佳選擇。此外也推薦下MVC庫、jQueryUI庫等等。

代碼整理

構(gòu)思清楚，再寫代碼，你已經(jīng)做到了。

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

所以，「重構(gòu)」的時候，除非是時間緊迫，永遠不要松懈代碼質(zhì)量。

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

代碼中邏輯沒有分塊、沒有空行、沒有注釋、看起來很累，建議對代碼進行分塊，比如將變量集中在頭部定義，然后處理一些賦值，最后執(zhí)行一些其它的函數(shù)。具體到這個例子，有很多不恰當?shù)牡胤?，比如可以先var_height；然后在條件分支中進行賦值，比如在一堆賦值語句中間夾雜了一個parseTemplate。

“_”用得太多，this._var這個可以理解，因為要區(qū)分是否私有變量，但是var_height這個完全沒有必要加，加得太多反而看著很累，而且也沒有任何區(qū)分的意義。

沒有將常用的變量緩存，這里最應該緩存的是this._options，要不然看起來很亂，而且緩存起來對性能也是有好處的。

對象的規(guī)劃（命名）不清晰，比如this._options和this.opts什么關系？我反正是看不明白。

代碼風格不統(tǒng)一，比如訪問對象，之前都是this._options.height，為什么后面出來一個this._options.data['head']？用this._options.data.head不是更清晰么？

函數(shù)內(nèi)變量名混亂（和第四點很像），比如第二個函數(shù)中id和_id什么關系？為什么不用aaaId和bbbId？cre又是什么，難道是createElement縮寫？變量盡量起有意義的，可區(qū)分的名字。

函數(shù)名稱表義不明，命名不符合大部分規(guī)范約定。第一眼看到_isHaveTable，我第一反應是，這應該是類似returntrue或者returnfalse之類的吧。結(jié)果一看，這么長，難道返回在后面？又往后看了一眼，這根本就沒有返回啊！那為什么要用_isHaveTable?。縚is開頭的函數(shù)明明白白就應該返回一個true或者false埃

以上是比較精彩的回答。保持適當?shù)目崭瘛L格統(tǒng)一、使用一些約定成俗的命名規(guī)則，比如局部變量名應該盡可能短，而方法名應該盡可能完整。

各位網(wǎng)友們，你們又有哪些妙招呢？不妨發(fā)來和我們一起探討探討吧！