前端代碼規(guī)范

1、福寶童趣201661區(qū)項(xiàng)目前端代碼規(guī)范代碼規(guī)范六一區(qū)項(xiàng)目前端組文檔控制更改記錄日期作者版本更改參考2016-8-151.0審閱姓名職位分發(fā)拷貝號姓名地點(diǎn)1234目錄代碼規(guī)范前端編碼規(guī)范（1） 一般規(guī)范這是一份旨在增強(qiáng)團(tuán)隊(duì)的開發(fā)協(xié)作，提高代碼質(zhì)量和打造開發(fā)基石的編碼風(fēng)格規(guī)范，其中包含了 HTML, JavaScript 和 CSS/SCSS 這幾個(gè)部分。我們知道，當(dāng)一個(gè)團(tuán)隊(duì)開始指定并實(shí)行編碼規(guī)范的話，錯(cuò)誤就會變得更加顯而易見。如果一段特定的代碼不符合規(guī)范的話，它有可能只是代碼風(fēng)格錯(cuò)誤，而也有可能會是 bug。早期指定規(guī)范就使得代碼審核得以更好的開展，并且可以更精確的地定位到錯(cuò)誤。只要開發(fā)者們能夠

2、保證源代碼源文件都嚴(yán)格遵循規(guī)范，那接下去所使用的混淆、壓縮和編譯工具則可投其所好不盡相同。文件命名規(guī)范在 web 項(xiàng)目中，所有的文件名應(yīng)該都遵循同一命名約定。以可讀性而言，減號（-）是用來分隔文件名的不二之選。同時(shí)它也是常見的 URL 分隔符（i.e. / or /請確保文件命名總是以字母開頭而不是數(shù)字。而以特殊字符開頭命名的文件，一般都有特殊的含義與用處（比如 compass1 中的下劃線就是用來標(biāo)記跳過直接編譯的文件用的）。資源的字母名稱必須全為小寫，這是因?yàn)樵谀承Υ笮懽帜该舾械牟僮飨到y(tǒng)中，當(dāng)文件通過工具壓縮混淆后，或者人為修改過后，大小寫不同而導(dǎo)致引用文件不同的錯(cuò)誤，很難被發(fā)現(xiàn)。還有

3、一些情況下，需要對文件增加前后綴或特定的擴(kuò)展名（比如 .min.js, .min.css），抑或一串前綴（比如 3fa89b.main.min.css）。這種情況下，建議使用點(diǎn)分隔符來區(qū)分這些在文件名中帶有清晰意義的元數(shù)據(jù)。不推薦推薦推薦協(xié)議規(guī)范不要指定引入資源所帶的具體協(xié)議。當(dāng)引入圖片或其他媒體文件，還有樣式和腳本時(shí)，URLs 所指向的具體路徑，不要指定協(xié)議部分（http:, https:），除非這兩者協(xié)議都不可用。不指定協(xié)議使得 URL 從絕對的獲取路徑轉(zhuǎn)變?yōu)橄鄬Φ模谡埱筚Y源協(xié)議無法確定時(shí)非常好用，而且還能為文件大小節(jié)省幾個(gè)字節(jié)。不推薦推薦不推薦推薦書寫規(guī)范文本縮進(jìn)一次縮進(jìn)兩個(gè)空格。注釋

4、注釋是你自己與你的小伙伴們了解代碼寫法和目的的唯一途徑。特別是在寫一些看似瑣碎的無關(guān)緊要的代碼時(shí)，由于記憶點(diǎn)不深刻，注釋就變得尤為重要了。編寫自解釋代碼只是一個(gè)傳說，沒有任何代碼是可以完全自解釋的。而代碼注釋，則是永遠(yuǎn)也不嫌多。當(dāng)你寫注釋時(shí)一定要注意：不要寫你的代碼都干了些什么，而要寫你的代碼為什么要這么寫，背后的考量是什么。當(dāng)然也可以加入所思考問題或是解決方案的鏈接地址。不推薦推薦一些注釋工具可以幫助你寫出更好的注釋。JSDoc 或 YUIDoc 就是用來寫 JavaScript 注釋用的。你甚至可以使用工具來為這些注釋生成文檔，這也是激勵(lì)開發(fā)者們寫注釋的一個(gè)好方法，因?yàn)橐坏┯辛诉@樣方便的生

5、成文檔的工具，他們通常會開始花更多時(shí)間在注釋細(xì)節(jié)上。代碼走查對于比較寬松自由的編程語言來說，嚴(yán)格遵循編碼規(guī)范和格式化風(fēng)格指南就顯得極為重要。遵循規(guī)范固然很好，但是有自動化流程來確保其執(zhí)行情況，豈不更佳。Trust is good, control is better.對于 JavaScript，建議使用 JSLint 或 JSHint。前端編碼規(guī)范（2） HTML 規(guī)范文檔類型推薦使用 HTML5 的文檔類型申明： .（建議使用 text/html 格式的 HTML。避免使用 XHTML。XHTML 以及它的屬性，比如 application/xhtml+xml 在瀏覽器中的應(yīng)用支持與優(yōu)化空間

6、都十分有限）。HTML 中最好不要將無內(nèi)容元素1 的標(biāo)簽閉合，例如：使用 而非 HTML 驗(yàn)證一般情況下，建議使用能通過標(biāo)準(zhǔn)規(guī)范驗(yàn)證的 HTML 代碼，除非在性能優(yōu)化和控制文件大小上不得不做出讓步。使用諸如 W3C HTML validator 這樣的工具來進(jìn)行檢測。規(guī)范化的 HTML 是顯現(xiàn)技術(shù)要求與局限的顯著質(zhì)量基線，它促進(jìn)了 HTML 被更好地運(yùn)用。不推薦推薦省略可選標(biāo)簽HTML5 規(guī)范中規(guī)定了 HTML 標(biāo)簽是可以省略的。但從可讀性來說，在開發(fā)的源文件中最好不要這樣做，因?yàn)槭÷詷?biāo)簽可能會導(dǎo)致一些問題。省略一些可選的標(biāo)簽確實(shí)使得頁面大小減少，這很有用，尤其是對于一些大型網(wǎng)站來說。為了達(dá)到

7、這一目的，我們可以在開發(fā)后期對頁面進(jìn)行壓縮處理，在這個(gè)環(huán)節(jié)中這些可選的標(biāo)簽完全就可以省略掉了。腳本加載出于性能考慮，腳本異步加載很關(guān)鍵。一段腳本放置在 內(nèi)，比如 ，其加載會一直阻塞 DOM 解析，直至它完全地加載和執(zhí)行完畢。這會造成頁面顯示的延遲。特別是一些重量級的腳本，對用戶體驗(yàn)來說那真是一個(gè)巨大的影響。異步加載腳本可緩解這種性能影響。如果只需兼容 IE10+，可將 HTML5 的 async 屬性加至腳本中，它可防止阻塞 DOM 的解析，甚至你可以將腳本引用寫在 里也沒有影響。如需兼容老舊的瀏覽器，實(shí)踐表明可使用用來動態(tài)注入腳本的腳本加載器。你可以考慮 yepnope 或 labjs。注入

8、腳本的一個(gè)問題是：一直要等到 CSS 對象文檔已就緒，它們才開始加載（短暫地在 CSS 加載完畢之后），這就對需要及時(shí)觸發(fā)的 JS 造成了一定的延遲，這多多少少也影響了用戶體驗(yàn)吧。終上所述，兼容老舊瀏覽器(IE9-)時(shí)，應(yīng)該遵循以下最佳實(shí)踐。腳本引用寫在 body 結(jié)束標(biāo)簽之前，并帶上 async 屬性。這雖然在老舊瀏覽器中不會異步加載腳本，但它只阻塞了 body 結(jié)束標(biāo)簽之前的 DOM 解析，這就大大降低了其阻塞影響。而在現(xiàn)代瀏覽器中，腳本將在 DOM 解析器發(fā)現(xiàn) body 尾部的 script 標(biāo)簽才進(jìn)行加載，此時(shí)加載屬于異步加載，不會阻塞 CSSOM（但其執(zhí)行仍發(fā)生在 CSSOM 之后）

9、。所有瀏覽器中，推薦只在現(xiàn)代瀏覽器中，推薦語義化根據(jù)元素（有時(shí)被錯(cuò)誤地稱作“標(biāo)簽”）其被創(chuàng)造出來時(shí)的初始意義來使用它。打個(gè)比方，用 heading 元素來定義頭部標(biāo)題，p 元素來定義文字段落，用 a 元素來定義鏈接錨點(diǎn)，等等。有根據(jù)有目的地使用 HTML 元素，對于可訪問性、代碼重用、代碼效率來說意義重大。以下示例列出了一些的語義化 HTML 主要情況：不推薦 推薦 不推薦推薦盡量用 alt 標(biāo)簽去描述圖片，設(shè)想你需要對于那些只能通過語音或者看不見圖片的用戶表達(dá)圖片到底是什么。不推薦推薦關(guān)注點(diǎn)分離理解 web 中如何和為何區(qū)分不同的關(guān)注點(diǎn)，這很重要。這里的關(guān)注點(diǎn)主要指的是：信息（HTML 結(jié)構(gòu)

10、）、外觀（CSS）和行為（JavaScript）。為了使它們成為可維護(hù)的干凈整潔的代碼，我們要盡可能的將它們分離開來。嚴(yán)格地保證結(jié)構(gòu)、表現(xiàn)、行為三者分離，并盡量使三者之間沒有太多的交互和聯(lián)系。就是說，盡量在文檔和模板中只包含結(jié)構(gòu)性的 HTML；而將所有表現(xiàn)代碼，移入樣式表中；將所有動作行為，移入腳本之中。在此之外，為使得它們之間的聯(lián)系盡可能的小，在文檔和模板中也盡量少地引入樣式和腳本文件。清晰的分層意味著：l 不使用超過一到兩張樣式表（i.e. main.css, vendor.css）l 不使用超過一到兩個(gè)腳本（學(xué)會用合并腳本）l 不使用行內(nèi)樣式（.no-good ）l 不在元素上使用 st

11、yle 屬性（）l 不使用行內(nèi)腳本（alert(no good)）l 不使用表象元素（i.e. , , , , ）l 不使用表象 class 名（i.e. red, left, center）不推薦推薦HTML內(nèi)容至上不要讓非內(nèi)容信息污染了你的 HTML?，F(xiàn)在貌似有一種傾向：通過 HTML 來解決設(shè)計(jì)問題，這是顯然是不對的。HTML 就應(yīng)該只關(guān)注內(nèi)容。HTML 標(biāo)簽的目的，就是為了不斷地展示內(nèi)容信息。l 不要引入一些特定的 HTML 結(jié)構(gòu)來解決一些視覺設(shè)計(jì)問題l 不要將 img 元素當(dāng)做專門用來做視覺設(shè)計(jì)的元素以下例子展示了誤將 HTML 用來解決設(shè)計(jì)問題的這兩種情況：不推薦推薦圖片和 SVG

12、 圖形能被引入到 HTML 中的唯一理由是它們呈現(xiàn)出了與內(nèi)容相關(guān)的一些信息。不推薦推薦Type屬性省略樣式表與腳本上的 type 屬性。鑒于 HTML5 中以上兩者默認(rèn)的 type 值就是 text/css 和 text/javascript，所以 type 屬性一般是可以忽略掉的。甚至在老舊版本的瀏覽器中這么做也是安全可靠的。不推薦推薦可用性如果 HTML5 語義化標(biāo)簽使用得當(dāng)，許多可用性問題已經(jīng)引刃而解。ARIA 規(guī)則在一些語義化的元素上可為其添上默認(rèn)的可用性角色屬性，使用得當(dāng)?shù)脑捯咽咕W(wǎng)站的可用性大部分成立。假如你使用 nav, aside, main, footer 等元素，ARIA 規(guī)

13、則會在其上應(yīng)用一些關(guān)聯(lián)的默認(rèn)值。更多細(xì)節(jié)可參考 ARIA specification另外一些角色屬性則能夠用來呈現(xiàn)更多可用性情景（i.e. role=tab）。Tab Index 在可用性上的運(yùn)用檢查文檔中的 tab 切換順序并傳值給元素上的 tabindex，這可以依據(jù)元素的重要性來重新排列其 tab 切換順序。你可以設(shè)置 tabindex=-1 在任何元素上來禁用其 tab 切換。當(dāng)你在一個(gè)默認(rèn)不可聚焦的元素上增加了功能，你應(yīng)該總是為其加上 tabindex 屬性使其變?yōu)榭删劢範(fàn)顟B(tài)，而且這也會激活其 CSS 的偽類 :focus。選擇合適的 tabindex 值，或是直接使用 tabind

14、ex=0 將元素們組織成同一 tab 順序水平，并強(qiáng)制干預(yù)其自然閱讀順序。微格式在 SEO 和可用性上的運(yùn)用如果 SEO 和可用性環(huán)境條件允許的話，建議考慮采用微格式。微格式是通過在元素標(biāo)簽上申明一系列特定數(shù)據(jù)來達(dá)成特定語義的方法。谷歌、微軟和雅虎對如何使用這些額外的數(shù)據(jù)一定程度上的達(dá)成一致，如果正確的使用，這將給搜索引擎優(yōu)化帶來巨大的好處。你可以訪問 獲得更多內(nèi)容細(xì)節(jié)?？匆粋€(gè)電影網(wǎng)站的簡單例子：不帶微格式帶有微格式ID 和錨點(diǎn)通常一個(gè)比較好的做法是將頁面內(nèi)所有的頭部標(biāo)題元素都加上 ID. 這樣做，頁面 URL 的 hash 中帶上對應(yīng)的 ID 名稱，即形成描點(diǎn)，方便跳轉(zhuǎn)

15、至對應(yīng)元素所處位置。打個(gè)比方，當(dāng)你在瀏覽器中輸入 URL http:/your- H3 上。格式化規(guī)則在每一個(gè)塊狀元素，列表元素和表格元素后，加上一新空白行，并對其子孫元素進(jìn)行縮進(jìn)。內(nèi)聯(lián)元素寫在一行內(nèi)，塊狀元素還有列表和表格要另起一行。（如果由于換行的空格引發(fā)了不可預(yù)計(jì)的問題，那將所有元素并入一行也是可以接受的，格式警告總好過錯(cuò)誤警告）。推薦HTML 引號使用雙引號(“”) 而不是單引號(”) 。不推薦推薦前端編碼規(guī)范（3） CSS 和 Sass (SCSS) 規(guī)范ID and class namingID和class(類)名總是使用可以反應(yīng)元素目的和用途的名稱，或其他通用名稱。代替表象和晦澀

16、難懂的名稱。應(yīng)該首選具體和反映元素目的的名稱，因?yàn)檫@些是最可以理解的，而且發(fā)生變化的可能性最小。通用名稱只是多個(gè)元素的備用名，他們兄弟元素之間是一樣的，沒有特別意義。區(qū)分他們，使他們具有特殊意義，通常需要為“幫手”。盡管class(類)名和ID 的語義化對于計(jì)算機(jī)解析來說沒有什么實(shí)際的意義，語義化的名稱 通常是正確的選擇，因?yàn)樗鼈兯淼男畔⒑x，不包含表現(xiàn)的限制。不推薦推薦合理的避免使用ID一般情況下ID不應(yīng)該被應(yīng)用于樣式。ID的樣式不能被復(fù)用并且每個(gè)頁面中你只能使用一次ID。使用ID唯一有效的是確定網(wǎng)頁或整個(gè)站點(diǎn)中的位置。盡管如此，你應(yīng)該始終考慮使用class，而不是id，除非只使用一次。

17、不推薦推薦另一個(gè)反對使用ID的觀點(diǎn)是含有ID選擇器權(quán)重很高。一個(gè)只包含一個(gè)ID選擇器權(quán)重高于包含1000個(gè)class(類)名的選擇器，這使得它很奇怪。CSS選擇器中避免標(biāo)簽名當(dāng)構(gòu)建選擇器時(shí)應(yīng)該使用清晰， 準(zhǔn)確和有語義的class(類)名。不要使用標(biāo)簽選擇器。 如果你只關(guān)心你的class(類)名，而不是你的代碼元素，這樣會更容易維護(hù)。從分離的角度考慮,在表現(xiàn)層中不應(yīng)該分配html標(biāo)記/語義。它可能是一個(gè)有序列表需要被改成一個(gè)無序列表，或者一個(gè)div將被轉(zhuǎn)換成article。如果你只使用具有實(shí)際意義的class(類)名，并且不使用元素選擇器，那么你只需要改變你的html標(biāo)記，而不用改動你的CSS。

18、不推薦推薦縮寫屬性CSS提供了各種縮寫屬性（如 font 字體）應(yīng)該盡可能使用，即使在只設(shè)置一個(gè)值的情況下。使用縮寫屬性對于代碼效率和可讀性是有很有用的。不推薦推薦0 和 單位省略“0”值后面的單位。不要在0值后面使用單位，除非有值。不推薦推薦十六進(jìn)制表示法在可能的情況下，使用3個(gè)字符的十六進(jìn)制表示法。顏色值允許這樣表示，3個(gè)字符的十六進(jìn)制表示法更簡短。始終使用小寫的十六進(jìn)制數(shù)字。不推薦推薦ID 和 Class（類）名的分隔符使用連字符（中劃線）分隔ID和Class（類）名中的單詞。為了增強(qiáng)課理解性，在選擇器中不要使用除了連字符（中劃線）以為的任何字符（包括沒有）來連接單詞和縮寫。另外，作為該

19、標(biāo)準(zhǔn)，預(yù)設(shè)屬性選擇器能識別連字符（中劃線）作為單詞attribute|=value的分隔符，所以最好的堅(jiān)持使用連字符作為分隔符。不推薦推薦Hacks避免用戶代理檢測以及CSS“hacks” 首先嘗試不同的方法。通過用戶代理檢測或特殊的CSS濾鏡，變通的方法和 hacks 很容易解決樣式差異。為了達(dá)到并保持一個(gè)有效的和可管理的代碼庫，這兩種方法都應(yīng)該被認(rèn)為是最后的手段。換句話說，從長遠(yuǎn)來看，用戶代理檢測和hacks會傷害項(xiàng)目，作為項(xiàng)目往往應(yīng)該采取阻力最小的途徑。也就是說，輕易允許使用用戶代理檢測和hacks 以后將過于頻繁。聲明順序這是一個(gè)選擇器內(nèi)書寫CSS屬性順序的大致輪廓。這是為了保證更好的

20、可讀性和可掃描重要。作為最佳實(shí)踐，我們應(yīng)該遵循以下順序（應(yīng)該按照下表的順序）：1. 結(jié)構(gòu)性屬性：1. display2. position, left, top, right etc.3. overflow, float, clear etc.4. margin, padding2. 表現(xiàn)性屬性：1 background, border etc.2 font, text不推薦推薦聲明結(jié)束為了保證一致性和可擴(kuò)展性，每個(gè)聲明應(yīng)該用分號結(jié)束，每個(gè)聲明換行。不推薦推薦屬性名結(jié)束屬性名的冒號后使用一個(gè)空格。出于一致性的原因，屬性和值（但屬性和冒號之間沒有空格）的之間始終使用一個(gè)空格。不推薦推薦選擇器和聲

21、明分離每個(gè)選擇器和屬性聲明總是使用新的一行。不推薦推薦規(guī)則分隔規(guī)則之間始終有一個(gè)空行（雙換行符）分隔。推薦CSS引號屬性選擇器或?qū)傩灾涤秒p引號（”），而不是單引號（”）括起來。URI值（url()）不要使用引號。不推薦推薦選擇器嵌套 (SCSS)在Sass中你可以嵌套選擇器，這可以使代碼變得更清潔和可讀。嵌套所有的選擇器，但盡量避免嵌套沒有任何內(nèi)容的選擇器。如果你需要指定一些子元素的樣式屬性，而父元素將不什么樣式屬性，可以使用常規(guī)的CSS選擇器鏈。這將防止您的腳本看起來過于復(fù)雜。不推薦不推薦推薦嵌套中引入 空行 (SCSS)嵌套選擇器和CSS屬性之間空一行。不推薦推薦上下文媒體查詢(SCSS)

22、在Sass中，當(dāng)你嵌套你的選擇器時(shí)也可以使用上下文媒體查詢。在Sass中，你可以在任何給定的嵌套層次中使用媒體查詢。由此生成的CSS將被轉(zhuǎn)換，這樣的媒體查詢將包裹選擇器的形式呈現(xiàn)。這技術(shù)非常方便，有助于保持媒體查詢屬于的上下文。第一種方法這可以讓你先寫你的手機(jī)樣式，然后在任何你需要的地方用上下文媒體查詢以提供桌面樣式。不推薦 推薦 嵌套順序和父級選擇器(SCSS)當(dāng)使用Sass的嵌套功能的時(shí)候，重要的是有一個(gè)明確的嵌套順序，以下內(nèi)容是一個(gè)SCSS塊應(yīng)具有的順序。1 當(dāng)前選擇器的樣式屬性2 父級選擇器的偽類選擇器 (:first-letter, :hover, :active etc)3 偽類元

23、素 (:before and :after)4 父級選擇器的聲明樣式 (.selected, .active, .enlarged etc.)5 用Sass的上下文媒體查詢6 子選擇器作為最后的部分推薦 前端編碼風(fēng)格規(guī)范（4） JavaScript 規(guī)范全局命名空間污染與 IIFE總是將代碼包裹成一個(gè) IIFE(Immediately-Invoked Function Expression)，用以創(chuàng)建獨(dú)立隔絕的定義域。這一舉措可防止全局命名空間被污染。IIFE 還可確保你的代碼不會輕易被其它全局命名空間里的代碼所修改（i.e. 第三方庫，window 引用，被覆蓋的未定義的關(guān)鍵字等等）。不推薦

24、推薦IIFE（立即執(zhí)行的函數(shù)表達(dá)式）無論何時(shí)，想要?jiǎng)?chuàng)建一個(gè)新的封閉的定義域，那就用 IIFE。它不僅避免了干擾，也使得內(nèi)存在執(zhí)行完后立即釋放。所有腳本文件建議都從 IIFE 開始。立即執(zhí)行的函數(shù)表達(dá)式的執(zhí)行括號應(yīng)該寫在外包括號內(nèi)。雖然寫在內(nèi)還是寫在外都是有效的，但寫在內(nèi)使得整個(gè)表達(dá)式看起來更像一個(gè)整體，因此推薦這么做。不推薦推薦so，用下列寫法來格式化你的 IIFE 代碼：如果你想引用全局變量或者是外層 IIFE 的變量，可以通過下列方式傳參：嚴(yán)格模式ECMAScript 5 嚴(yán)格模式可在整個(gè)腳本或獨(dú)個(gè)方法內(nèi)被激活。它對應(yīng)不同的 javascript 語境會做更加嚴(yán)格的錯(cuò)誤檢查。嚴(yán)格模式也確保

25、了 javascript 代碼更加的健壯，運(yùn)行的也更加快速。嚴(yán)格模式會阻止使用在未來很可能被引入的預(yù)留關(guān)鍵字。你應(yīng)該在你的腳本中啟用嚴(yán)格模式，最好是在獨(dú)立的 IIFE 中應(yīng)用它。避免在你的腳本第一行使用它而導(dǎo)致你的所有腳本都啟動了嚴(yán)格模式，這有可能會引發(fā)一些第三方類庫的問題。不推薦推薦變量聲明總是使用 var 來聲明變量。如不指定 var，變量將被隱式地聲明為全局變量，這將對變量難以控制。如果沒有聲明，變量處于什么定義域就變得不清（可以是在 Document 或 Window 中，也可以很容易地進(jìn)入本地定義域）。所以，請總是使用 var 來聲明變量。采用嚴(yán)格模式帶來的好處是，當(dāng)你手誤輸入錯(cuò)誤的

26、變量名時(shí)，它可以通過報(bào)錯(cuò)信息來幫助你定位錯(cuò)誤出處。不推薦推薦理解 JavaScript 的定義域和定義域提升在 JavaScript 中變量和方法定義會自動提升到執(zhí)行之前。JavaScript 只有 function 級的定義域，而無其他很多編程語言中的塊定義域，所以使得你在某一 function 內(nèi)的某語句和循環(huán)體中定義了一個(gè)變量，此變量可作用于整個(gè) function 內(nèi)，而不僅僅是在此語句或循環(huán)體中，因?yàn)樗鼈兊穆暶鞅?JavaScript 自動提升了。我們通過例子來看清楚這到底是怎么一回事：原 function被JS提升過后 根據(jù)以上提升過程，你是否可理解以下代碼？有效代碼正如你所看到的這

27、段令人充滿困惑與誤解的代碼導(dǎo)致了出人意料的結(jié)果。只有良好的聲明習(xí)慣，才能盡可能的避免這類錯(cuò)誤風(fēng)險(xiǎn)。提升聲明為避免上一章節(jié)所述的變量和方法定義被自動提升造成誤解，把風(fēng)險(xiǎn)降到最低，我們應(yīng)該手動地顯示地去聲明變量與方法。也就是說，所有的變量以及方法，應(yīng)當(dāng)定義在 function 內(nèi)的首行。只用一個(gè)var關(guān)鍵字聲明，多個(gè)變量用逗號隔開不推薦推薦把賦值盡量寫在變量申明中。不推薦推薦總是使用帶類型判斷的比較判斷總是使用=精確的比較操作符，避免在判斷的過程中，由 JavaScript 的強(qiáng)制類型轉(zhuǎn)換所造成的困擾。如果你使用=操作符，那比較的雙方必須是同一類型為前提的條件下才會有效。在只使用=的情況下，Jav

28、aScript 所帶來的強(qiáng)制類型轉(zhuǎn)換使得判斷結(jié)果跟蹤變得復(fù)雜，下面的例子可以看出這樣的結(jié)果有多怪了：明智地使用真假判斷當(dāng)我們在一個(gè) if 條件語句中使用變量或表達(dá)式時(shí)，會做真假判斷。if(a = true)是不同于if(a)的。后者的判斷比較特殊，我們稱其為真假判斷。這種判斷會通過特殊的操作將其轉(zhuǎn)換為 true 或 false，下列表達(dá)式統(tǒng)統(tǒng)返回 false：false,0,undefined,null,NaN,（空字符串）.這種真假判斷在我們只求結(jié)果而不關(guān)心過程的情況下，非常的有幫助。以下示例展示了真假判斷是如何工作的：變量賦值時(shí)的邏輯操作邏輯操作符 | 和 & 也可被用來返回布爾值。如果操

29、作對象為非布爾對象，那每個(gè)表達(dá)式將會被自左向右地做真假判斷?；诖瞬僮?，最終總有一個(gè)表達(dá)式被返回回來。這在變量賦值時(shí)，是可以用來簡化你的代碼的。不推薦推薦這一小技巧經(jīng)常用來給方法設(shè)定默認(rèn)的參數(shù)。分號總是使用分號，因?yàn)殡[式的代碼嵌套會引發(fā)難以察覺的問題。當(dāng)然我們更要從根本上來杜絕這些問題1 。以下幾個(gè)示例展示了缺少分號的危害：So what happens?1. JavaScript 錯(cuò)誤 首先返回 42 的那個(gè) function 被第二個(gè) function 當(dāng)中參數(shù)傳入調(diào)用，接著數(shù)字 42 也被“調(diào)用”而導(dǎo)致出錯(cuò)。2. 八成你會得到 no such property in undefined

30、的錯(cuò)誤提示，因?yàn)樵谡鎸?shí)環(huán)境中的調(diào)用是這個(gè)樣子：xffVersion, ieVersionisIE().3. die 總是被調(diào)用。因?yàn)閿?shù)組減 1 的結(jié)果是 NaN，它不等于任何東西（無論 resultOfOperation 是否返回 NaN）。所以最終的結(jié)果是 die() 執(zhí)行完所獲得值將賦給 THINGS_TO_EAT.Why?JavaScript 中語句要以分號結(jié)束，否則它將會繼續(xù)執(zhí)行下去，不管換不換行。以上的每一個(gè)示例中，函數(shù)聲明或?qū)ο蠡驍?shù)組，都變成了在一句語句體內(nèi)。要知道閉合圓括號并不代表語句結(jié)束，JavaScript 不會終結(jié)語句，除非它的下一個(gè) token 是一個(gè)中綴符2 或者是圓括

31、號操作符。這真是讓人大吃一驚，所以乖乖地給語句末加上分號吧。澄清：分號與函數(shù)分號需要用在表達(dá)式的結(jié)尾，而并非函數(shù)聲明的結(jié)尾。區(qū)分它們最好的例子是：嵌套函數(shù)嵌套函數(shù)是非常有用的，比如用在持續(xù)創(chuàng)建和隱藏輔助函數(shù)的任務(wù)中。你可以非常自由隨意地使用它們。語句塊內(nèi)的函數(shù)聲明切勿在語句塊內(nèi)聲明函數(shù)，在 ECMAScript 5 的嚴(yán)格模式下，這是不合法的。函數(shù)聲明應(yīng)該在定義域的頂層。但在語句塊內(nèi)可將函數(shù)申明轉(zhuǎn)化為函數(shù)表達(dá)式賦值給變量。不推薦推薦異常基本上你無法避免出現(xiàn)異常，特別是在做大型開發(fā)時(shí)（使用應(yīng)用開發(fā)框架等等）。在沒有自定義異常的情況下，從有返回值的函數(shù)中返回錯(cuò)誤信息一定非常的棘手，更別提多不優(yōu)雅了

32、。不好的解決方案包括了傳第一個(gè)引用類型來接納錯(cuò)誤信息，或總是返回一個(gè)對象列表，其中包含著可能的錯(cuò)誤對象。以上方式基本上是比較簡陋的異常處理方式。適時(shí)可做自定義異常處理。在復(fù)雜的環(huán)境中，你可以考慮拋出對象而不僅僅是字符串（默認(rèn)的拋出值）。標(biāo)準(zhǔn)特性總是優(yōu)先考慮使用標(biāo)準(zhǔn)特性。為了最大限度地保證擴(kuò)展性與兼容性，總是首選標(biāo)準(zhǔn)的特性，而不是非標(biāo)準(zhǔn)的特性（例如：首選 string.charAt(3) 而不是 string3；首選 DOM 的操作方法來獲得元素引用，而不是某一應(yīng)用特定的快捷方法）。簡易的原型繼承如果你想在 JavaScript 中繼承你的對象，請遵循一個(gè)簡易的模式來創(chuàng)建此繼承。如果你預(yù)計(jì)你會遇

33、上復(fù)雜對象的繼承，那可以考慮采用一個(gè)繼承庫，比如 Proto.js by Axel Rauschmayer.簡易繼承請用以下方式：使用閉包閉包的創(chuàng)建也許是 JS 最有用也是最易被忽略的能力了。不推薦接下來的改進(jìn)雖然已經(jīng)解決了上述例子中的問題或 bug，但還是違反了不在循環(huán)中創(chuàng)建函數(shù)或閉包的原則。不推薦接下來的改進(jìn)已解決問題，而且也遵循了規(guī)范?？墒?，你會發(fā)現(xiàn)看上去似乎過于復(fù)雜繁冗了，應(yīng)該會有更好的解決方案吧。不完全推薦將循環(huán)語句轉(zhuǎn)換為函數(shù)執(zhí)行的方式問題能得到立馬解決，每一次循環(huán)都會對應(yīng)地創(chuàng)建一次閉包。函數(shù)式的風(fēng)格更加值得推薦，而且看上去也更加地自然和可預(yù)料。推薦eval函數(shù)eval() 不但混淆語境還很危險(xiǎn)，總會有比這更好、更清晰、更安全的另一種方案來寫你的代碼，因此盡量不要使用eval函數(shù)。this關(guān)鍵字只在對象構(gòu)造器、方法和在設(shè)定的閉包中使用 this 關(guān)鍵字。this 的語義在此有些誤導(dǎo)。它時(shí)而指向全局對象（大多數(shù)時(shí)），時(shí)而指向調(diào)用者的定義域（在 eval 中），時(shí)而指向 DOM 樹中的某一節(jié)點(diǎn)（當(dāng)用事件處理綁定到 HTML 屬性上時(shí)），時(shí)而指向一個(gè)新創(chuàng)建的對象（在構(gòu)造器中），還時(shí)而指向其它的一些對象（如果函數(shù)被 call() 和 apply() 執(zhí)行和調(diào)用時(shí)）。正因?yàn)樗侨绱巳菀椎乇桓沐e(cuò)