一直以來，關於「代碼規範」的話題都備受關注，業界甚至有很多流傳甚廣的段子不斷調侃之。既然代碼規範能引起這麼大的共鳴，那麼今天我們談談一個程式設計師的自我修養——如何寫出優雅的代碼？
一、接口的流暢性
好的接口是流暢易懂的，他主要體現如下幾個方面：
- 簡單
操作某個元素的css屬性，下面是原生的方法:
document.querySelectorAll('#id').style.color = 'red';
複製代碼
封裝之後
function a(selector, color) {
document.querySelectorAll(selector)[0].style.color = color
}
a('#a', 'red');
複製代碼
從幾十個字母長長的一行到簡簡單單的一個函數調用，體現了api簡單易用
- 可閱讀性
a(『#a』, 『red』)是個好函數，幫助我們簡單實用地改變某個元素，但問題來了，如果第一次使用改函數的人來說會比較困惑，a函數是啥函數，沒有人告訴他。開發接口有必要知道一點，人都是懶惰的，從顏色賦值這個函數來說，雖然少寫了代碼，但是增加了記憶成本。每次做這件事情的時候都需要有映射關係。 a—->color. 如果是簡單的幾個無所謂，但是通常一套框架都有幾十甚至上百的api，映射成本增加會使得程式設計師哥哥崩潰。 我們需要的就是使得接口有意義，下面我們改寫一下a函數：
function letSomeElementChangeColor(selector, color) {
document.querySelectorAll(selector, color);
}
複製代碼
letSomeElementChangeColor 相對於a來說被賦予了語言意義，任何人都會知道它的意義
- 減少記憶成本
我們剛剛的函數也是這樣的它太長了letSomeElementChangeColor雖然減少了映射成本，但是增加了記憶成本。要知道，包括學霸在內，任何人都不喜歡被單詞。原生獲取dom的api也同樣有這個問題 document.getElementsByClassName； document.getElementsByName; document.querySelectorAll;這些api給人的感覺就是單詞太長了，雖然他給出的意義是很清晰，然而這種做法是建立在犧牲簡易性的基礎上進行的。於是我們又再次改寫這個之前函數
function setColor(selector, color) {
// ...
}
複製代碼
在意義不做大的變化前提下，縮減函數名稱。使得它易讀易記易用；
- 可延伸
所謂延伸就是指函數的使用像流水一樣按照書寫的順序執行形成執行鏈條:
document.getElementById('id').style.color = 'red';
document.getElementById('id').style.fontSize = '12px';
document.getElementById('id').style.backgourdColor = 'pink';
複製代碼
用我們之前的之前的方法是再次封裝兩個函數 setFontSize, setbackgroundColor; 然後執行它們 setColor(『id』, 『red』); setFontSiez(『id』, 』12px』); setbackgroundColor(『id』, 『pink』); 顯然，這樣的做法沒有懶出境界來；id元素每次都需要重新獲取，影響性能，失敗；每次都需要添加新的方法 失敗 每次還要調用這些方法，還是失敗。下面我們將其改寫為可以延伸的函數 首先將獲取id方法封裝成對象,然後再對象的每個方法中返回這個對象：
function getElement(selector) {
this.style = document.querySelecotrAll(selector).style;
}
getElement.prototype.color = function(color) {
this.style.color = color;
return this;
}
getElement.prototype.background = function(bg) {
this.style.backgroundColor = color;
return this;
}
getElement.prototype.fontSize = function(size) {
this.style.fontSize = size;
return this;
}
//調用
var el = new getElement('#id')
el.color('red').background('pink').fontSize('12px');
複製代碼
簡單、流暢、易讀後面我們會在參數裡面講到如何繼續優化。所以，大家都比較喜歡用jquery的api，雖然一個$符號並不代表任何現實意義，但簡單的符號有利於我們的使用。它體現了以上的多種原則，簡單，易讀，易記，鏈式寫法，多參處理。
糟糕的:
document.getElementById('id').style.color = 'red';
document.getElementById('id').style.fontSize = '12px';
document.getElementById('id').style.backgourdColor = 'pink';
複製代碼
期望:
$('id').css({color:'red', fontSize:'12px', backgroundColor:'pink'})
複製代碼
二、一致性
- 接口的一致性
相關的接口保持一致的風格，一整套 API 如果傳遞一種熟悉和舒適的感覺，會大大減輕開發者對新工具的適應性。 命名這點事：既要短，又要自描述，最重要的是保持一致性 「在計算機科學界只有兩件頭疼的事：緩存失效和命名問題」 — Phil Karlton 選擇一個你喜歡的措辭，然後持續使用。選擇一種風格，然後保持這種風格。
糟糕的:
setColor,
letBackGround
changefontSize
makedisplay
複製代碼
期望:
setColor;
setBackground;
setFontSize
set.........
複製代碼
儘量地保持代碼風格和命名風格，使人讀你的代碼像是閱讀同一個人寫的文章一樣。
三、平衡
下一條原則是平衡，組織元素時不會讓某個部分過於重量級而蓋過其它部分，使用時不穩定。藝術作品裡，平衡就是視覺權重。即使不對稱，作品中仍能感覺到不對稱下的平衡，因為它遵循某種模式。上下文中的API設計的平衡，我特指代碼的視覺權重和可預測性（看得出功能）。
平衡的API讓人覺得其組成部分屬於彼此，他們行為相同，或互補地完成一個目標。通過擴展，APIs也可以感覺平衡，它們允許開發人員簡單的預測其他API並使用。如Modernizr的屬性測試，它們的平衡性在兩個方面，a)屬性名對應HTML5和CSS術語和API名稱，b)每個屬性測試統一地返回true或false值。
Modernizr.geolocation
Modernizr.localstorage
Modernizr.webworkers
Modernizr.canvas
Modernizr.borderradius
Modernizr.boxshadow
Modernizr.flexbox
複製代碼
訪問一個單一的屬性來告訴開發者需要了解到的相關屬性，以便通過它訪問每一個其他屬性，一個高質量API的強大之處就在於它的簡單。平衡性也保證了我寫和Modernizr交互的代碼在每次讀寫時具有相同的視覺加權。如何在我使用和訪問API時看起來和感覺上一樣，而不顧我的慣例。另一方面，如果Modernizr添加了一個polyfill Canvas的API，不僅僅是類庫的視覺加權受到新API的影響，Modernizr的範圍和用途也將大大擴大，並且我在和API交互時可預測性也受到了限制。
達到平衡的另一種方式是通過依靠開發人員對概念的熟悉獲得可預測性的結果。一個典型的例子就是jQuery’s selector syntax（jquery選擇器的語法），它映射css1-3的選擇器到自己的DOM選擇器引擎:
$("#grid") // Selects by ID
$("ul.nav > li") // All LIs for the UL with class "nav"
$("ul li:nth-child(2)") // Second item in each list
複製代碼
通過使用一個熟悉的概念並且映射到自己的類庫，jquery避免了新的選擇器語法，同事也創建了一個機制讓新用戶通過一個可預測的API快速的把類庫應用到生產.。
四、參數的處理
- 參數的類型
判斷參數的類型為你的程序提供穩定的保障
//我們規定，color接受字符串類型
function setColor(color) {
if(typeof color !== 'string') return;
// ..dosomething
}
複製代碼
- 使用json方式傳參
使用json的方式傳值很多好處，它可以給參數命名，可以忽略參數的具體位置，可以給參數默認值等等 比如下面這種糟糕的情況:
function fn(param1, param2...............paramN)
複製代碼
你必須對應地把每一個參數按照順序傳入，否則你的方法就會偏離你預期去執行，正確的方法是下面的做法。
function fn(json) {
//為必須的參數設置默認值
var default = extend({
param: 'default',
param1: 'default'
// ...
}, json)
}
複製代碼
這段函數代碼，即便你不傳任何參數進來，他也會預期運行。因為在聲明的時候，你會根據具體的業務決定參數的預設值。
五、可擴展性
軟體設計最重要的原則之一：永遠不修改接口，指擴展它！可擴展性同時會要求接口的職責單一，多職責的接口很難擴展。 舉個栗子：
需要同時改變某個元素的字體和背景
糟糕的:
function set(selector, color) {
document.querySelectroAll(selector).style.color = color;
document.querySelectroAll(selector).style.backgroundColor = color;
}
複製代碼
無法擴展改函數，如果需要再次改變字體的大小的話，只能修改此函數，在函數後面填加改變字體大小的代碼
期望:
function set(selector, color) {
var el = document.querySelectroAll(selector);
el.style.color = color;
el.style.backgroundColor = color;
return el;
}
複製代碼
需要設置字體、背景顏色和大小
function setAgain (selector, color, px) {
var el = set(selector, color)
el.style.fontSize = px;
return el;
}
複製代碼
以上只是簡單的添加顏色，業務複雜而代碼又不是你寫的時候，你就必須去閱讀之前的代碼再修改它，顯然是不符合開放-封閉原則的。修改後的function是返回了元素對象，使得下次需要改變時再次得到返回值做處理。
- this的運用
可擴展性還包括對this的以及call和apply方法的靈活運用：
function sayBonjour() {
alert(this.a)
}
obj.a = 1;
obj.say = sayBonjour;
obj.say();//1
//or
sayBonjour.call||apply(obj); //1
複製代碼
六、對錯誤的處理
- 預見錯誤
可以用 類型檢測 typeof 或者try…catch。 typeof 會強制檢測對象不拋出錯誤，對於未定義的變量尤其有用。
- 拋出錯誤
大多數開發者不希望出錯了還需要自己去找帶對應得代碼，最好方式是直接在console中輸出，告訴用戶發生了什麼事情。我們可以用到瀏覽器的輸出api:console.log/warn/error。你還可以為自己的程序留些後路: try…catch。
function error (a) {
if(typeof a !== 'string') {
console.error('param a must be type of string')
}
}
function error() {
try {
// some code excucete here maybe throw wrong
}catch(ex) {
console.wran(ex);
}
}
複製代碼
七、可預見性
可預見性味程序接口提供健壯性，為保證你的代碼順利執行，必須為它考慮到非正常預期的情況。我們看下不可以預見的代碼和可預見的代碼的區別用之前的setColor
糟糕的：
function set(selector, color) {
document.getElementById(selector).style.color = color;
}
複製代碼
期望：
zepto.init = function(selector, context) {
var dom
// If nothing given, return an empty Zepto collection
if (!selector) return zepto.Z()
// Optimize for string selectors
else if (typeof selector == 'string') {
selector = selector.trim()
// If it's a html fragment, create nodes from it
// Note: In both Chrome 21 and Firefox 15, DOM error 12
// is thrown if the fragment doesn't begin with <
if (selector[0] == '<' && fragmentRE.test(selector))
dom = zepto.fragment(selector, RegExp.$1, context), selector = null
// If there's a context, create a collection on that context first, and select
// nodes from there
else if (context !== undefined) return $(context).find(selector)
// If it's a CSS selector, use it to select nodes.
else dom = zepto.qsa(document, selector)
}
// If a function is given, call it when the DOM is ready
else if (isFunction(selector)) return $(document).ready(selector)
// If a Zepto collection is given, just return it
else if (zepto.isZ(selector)) return selector
else {
// normalize array if an array of nodes is given
if (isArray(selector)) dom = compact(selector)
// Wrap DOM nodes.
else if (isObject(selector))
dom = [selector], selector = null
// If it's a html fragment, create nodes from it
else if (fragmentRE.test(selector))
dom = zepto.fragment(selector.trim(), RegExp.$1, context), selector = null
// If there's a context, create a collection on that context first, and select
// nodes from there
else if (context !== undefined) return $(context).find(selector)
// And last but no least, if it's a CSS selector, use it to select nodes.
else dom = zepto.qsa(document, selector)
}
// create a new Zepto collection from the nodes found
return zepto.Z(dom, selector)
}
複製代碼
以上是zepto的源碼，可以看見，作者在預見傳入的參數時做了很多的處理。其實可預見性是為程序提供了若干的入口，無非是一些邏輯判斷而已。zepto在這裡使用了很多的是非判斷，同時導致了代碼的冗長，不適合閱讀。總之，可預見性真正需要你做的事多寫一些對位置實物的參數。把外部的檢測改為內部檢測。是的使用的人用起來舒心放心開心。吶！做人嘛最重要的就是海森啦。
八、注釋和文檔的可讀性
一個最好的接口是不需要文檔我們也會使用它，但是往往接口量一多和業務增加，接口使用起來也會有些費勁。所以接口文檔和注釋是需要認真書寫的。注釋遵循簡單扼要地原則，給多年後的自己也給後來者看：
//注釋接口，為了演示PPT用
function commentary() {
//如果你定義一個沒有字面意義的變量時，最好為它寫上注釋：a：沒用的變量，可以刪除
var a;
//在關鍵和有歧義的地方寫上注釋，猶如畫龍點睛：路由到hash介面後將所有的數據清空結束函數
return go.Navigate('hash', function(){
data.clear();
});
}
複製代碼
文章參考：賣燒烤夫斯基