五、變量類型透明化

　　因?yàn)?JS 是一個(gè)弱類型語言，在定義變量的時(shí)候，不會(huì)限制數(shù)據(jù)類型

　　但是我們?cè)诮o變量賦值的時(shí)候，也要盡可能的做到數(shù)據(jù)類型統(tǒng)一

　　當(dāng)你需要定義一些變量，在后期操作中進(jìn)行賦值的時(shí)候

　　盡可能在定義的時(shí)候，給一個(gè)初始值表示一下你變量將來要存儲(chǔ)的數(shù)據(jù)類型

　　比如：

　　var count = 0;

　　var name = '';

　　var boo = false;

　　var person = null;

　　var todoList = [ ];

　　如果你實(shí)在不想給一個(gè)初始值

　　也可以使用注釋的形式表明一下你定義的變量, 將來存儲(chǔ)的是什么類型的數(shù)據(jù)

　　var count /* Number */;

　　var name /* String */;

　　var boo /* Boolean */;

　　六、代碼書寫習(xí)慣

　　我們要保證一個(gè)良好的代碼書寫習(xí)慣

　　七、鏈?zhǔn)骄幊痰牧?xí)慣

　　我們來看一下下面這個(gè)代碼

　　[ ... ].map(function () {

　　// code ...

　　}).filter(function () {

　　// code ...

　　}).reduce(function () {

　　// code ...

　　})

　　其實(shí)沒啥問題, 而且也挺好的

　　更甚至當(dāng)代碼簡(jiǎn)單一些的時(shí)候有人把它寫成一行

　　[ ... ].map(function () { ... }).filter(function () { ... }).reduce(function () { ... })

　　但是到了后期修改的時(shí)候，問題就會(huì)逐步顯示，一旦修改了第一個(gè)，那么后面的都有可能會(huì)出現(xiàn)問題

　　而且當(dāng)代碼量過大的時(shí)候，很難保證你不修改串行了

　　· 我們可以把上面的代碼換成下面的方式

　　[ ... ]

　　.map(function () {

　　// code ...

　　})

　　.filter(function () {

　　// code ...

　　})

　　.reduce(function () {

　　// code ...

　　})

　　這樣的話，看起來會(huì)舒服的多

　　而且可以利用編輯器的代碼折疊，一個(gè)函數(shù)一個(gè)函數(shù)的來書寫

　　八、書寫運(yùn)算符的習(xí)慣

　　很多人喜歡相對(duì)緊湊的書寫結(jié)構(gòu)

　　比如下面的代碼

　　if (year%4===0&&year%100!==0||year%400===0) { ... }

　　很簡(jiǎn)單的一個(gè)判斷閏年的代碼

　　但是當(dāng)你的運(yùn)算符很緊湊的時(shí)候，那么看起來就會(huì)比較費(fèi)眼睛

　　相對(duì)來說，我更喜歡在運(yùn)算符兩邊都加上空格

　　讓結(jié)構(gòu)相對(duì)松散一些，看起來可能也容易一些

　　我們也不用擔(dān)心這些空格，后期處理都會(huì)幫我們處理掉的

　　if ( year % 4 === 0 && year % 100 !== 0 || year % 400 === 0) { ... }

　　還有一種寫法

　　if (

　　year % 4 === 0 &&

　　year % 100 !== 0 ||

　　year % 400 === 0

　　) { ... }

　　這個(gè)適用于條件比較長(zhǎng)的時(shí)候使用

　　看起來會(huì)更加清晰一些

　　九、函數(shù)調(diào)用傳遞參數(shù)

　　· 當(dāng)調(diào)用一個(gè)函數(shù)，需要傳遞一個(gè)函數(shù)作為參數(shù)的時(shí)候

　　· 我們通常都會(huì)直接書寫一個(gè)匿名函數(shù)或者箭頭函數(shù)在參數(shù)位置

　　· 或者說傳遞一個(gè)復(fù)雜數(shù)據(jù)類型作為參數(shù)的時(shí)候，都會(huì)直接講對(duì)應(yīng)的數(shù)組或者對(duì)象寫在參數(shù)位置

　　· 比如下面這段代碼

　　$.get('/xxx', {

　　a: 100,

　　b: 200

　　}, function (res) {

　　// code ...

　　}, 'json')

　　代碼沒有問題，但是一旦對(duì)象中數(shù)據(jù)過多

　　或者函數(shù)中代碼過多的時(shí)候

　　后期看起來就會(huì)很復(fù)雜

　　我會(huì)建議把這些內(nèi)容單獨(dú)書寫出來

　　var params = {

　　a: 100,

　　b: 200

　　}

　　function success(res) {

　　// code ...

　　}

　　$.get('/xxx', params, success, 'json')

　　這樣一來, 不管是修改, 還是增加一些內(nèi)容, 都會(huì)比較方便了

　　十、功能性函數(shù)的單獨(dú)封裝

　　把我們自定義的一些功能性函數(shù)進(jìn)行單獨(dú)的封裝，放在一個(gè)單獨(dú)的 JS 文件中進(jìn)行引入或者導(dǎo)入使用，其實(shí)就是模塊化的概念

　　十一、松散耦合

　　對(duì)于比較難以閱讀的代碼來說，強(qiáng)耦合的代碼是最難閱讀的，JS 代碼本身層面上的耦合我們就不說了，大家都應(yīng)該了解面向?qū)ο缶幊毯湍K化編程

　　十二、HTML 和 JavaScript 的耦合

　　在前端開發(fā)中，我們經(jīng)常會(huì)見到有些人寫代碼會(huì)把一些簡(jiǎn)單的事件直接寫到 html 結(jié)構(gòu)上

　　<button onclick="doSomething()" ></button> 

　　從代碼層面上來說完全沒有問題

　　但是實(shí)際上，這個(gè)是 HTML 和 JavaScript 的強(qiáng)耦合現(xiàn)象

　　第一: 每次對(duì)于代碼進(jìn)行的修改，都要從 HTML 和 JavaScript 兩個(gè)位置去進(jìn)行修改

　　第二: 代碼引入位置不可變，一定要保證在用戶點(diǎn)擊之前就已經(jīng)有函數(shù)存在了，不然一定會(huì)報(bào)錯(cuò)的

　　比較好的方法就是進(jìn)行 HTML 和 JavaScript 的分離

　　在 .js 文件中獲取 DOM 元素

　　通過事件綁定的形式來完成操作

　　var btn = document.querySelector('button')

　　btn.addEventListener('click', doSomething)

　　還有一種情況更常見, 就是在 JS 代碼中為了渲染頁面而進(jìn)行字符串拼接

container.innerHTML = `

<div>

...

<p> ... </p>

<span> ... </span>

</div>

　　這個(gè)代碼也是完全沒有問題的，而且大部分同學(xué)都會(huì)這樣書寫代碼，因?yàn)槭r(shí)省力

　　但是這樣的情況，一旦渲染到頁面上，出現(xiàn)樣式問題需要調(diào)整的時(shí)候

　　我們?cè)?HTML 結(jié)構(gòu)中很難找到內(nèi)容來修改，必須要到 JavaScript 代碼里面去修改

　　如果我們的字符串拼接是在循環(huán)里面完成的話，那么有可能你添加一個(gè)或者刪除一個(gè)標(biāo)簽的時(shí)候，導(dǎo)致整個(gè)頁面崩潰

　　比較好的做法

　　使用一些第三方小腳本或者模板引擎來進(jìn)行渲染：

　　比如：art-template / e.js / ...

　　真的需要這樣渲染的時(shí)候，那么在原始 html 結(jié)構(gòu)中以注釋的形式留下一部分渲染內(nèi)容

<div class="container">

    <!-- 商品詳情信息渲染結(jié)構(gòu)

    <div>

        ...

        <p> ... </p>

        <span> ... </span>

    </div>

    -->

</div>

　　· 當(dāng) HTML 和 JavaScript 解耦以后

　　· 可以大量節(jié)省我們的排錯(cuò)時(shí)間, 和錯(cuò)誤的準(zhǔn)確定位

　　十三、CSS 和 JavaScript 的耦合

　　在前端的開發(fā)中，使用 JS 來操作一些元素的樣式，是在常見不過的事情了

　　比如我們經(jīng)常會(huì)寫

　　ele.style.color = 'red' ;

　　ele.style.display = 'none' ;

　　這樣書寫代碼其實(shí)沒有大問題

　　對(duì)于渲染也不會(huì)造成很大的困擾

　　但是，一旦我們需要修改樣式的時(shí)候，那么就比較麻煩了

　　因?yàn)橛械臉邮娇赡苄枰?.css 文件內(nèi)修改，有的樣式需要在 .js 文件內(nèi)修改

　　· 比較好的做法是, 把我們需要修改的樣式寫成一個(gè)單獨(dú)類名下

　　· 放在 .css 文件內(nèi)

　　· 我們?cè)诖a里面通過操作元素的類名來進(jìn)行修改

　　ele.classList.add('active')

　　ele.classList.remove('active')

　　這樣做保證了樣式和行為的分離，我們?cè)谡{(diào)整頁面樣式的時(shí)候，不需要 JS，直接在 CSS 中修改就可以

　　十四、事件處理 和 應(yīng)用邏輯 的耦合

　　在開發(fā)過程中, 我們經(jīng)常要處理一些事件，并且在事件里面要進(jìn)行一些邏輯的運(yùn)算

　　比如：我們?cè)邳c(diǎn)擊登錄的時(shí)候，要對(duì)用戶填寫的內(nèi)容進(jìn)行一個(gè)正則的驗(yàn)證，然后提交到服務(wù)器

　　ele.addEventListener('submit', function () {

　　let username = xxx.value

　　let password = xxx.value

　　// 正則驗(yàn)證

　　if ( ... ) { ... }

　　if ( ... ) { ... }

　　// 提交到服務(wù)器

　　var xhr = new XMLHttpRequest()

　　xhr.open( ... )

　　xhr.send( ... )

　　xhr.onload = function () { ... }

　　})

　　這是一段合法的代碼

　　但是函數(shù)里面包含了太多的內(nèi)容

　　有事件處理

　　有邏輯處理

　　有請(qǐng)求發(fā)送

　　這樣就相當(dāng)于在一個(gè)函數(shù)里面做了太多的事情

　　這個(gè)代碼的邏輯運(yùn)算還是比較少的，但是一旦邏輯運(yùn)算多了以后，那么后期閱讀的時(shí)候就很麻煩了

　　我們可以把里面的邏輯運(yùn)算和請(qǐng)求發(fā)送都單獨(dú)提取出來，變成下面這個(gè)形式：

　　function validateValue(val) {

　　// 正則驗(yàn)證

　　if ( ... ) { ... }

　　if ( ... ) { ... }

　　// 將驗(yàn)證結(jié)果返回

　　return true // or false

　　}

　　function sendAjax() {

　　// 發(fā)送請(qǐng)求的業(yè)務(wù)邏輯

　　}

　　ele.addEventListener('submit', function () {

　　let username = xxx.value

　　let password = xxx.value

　　// 正則驗(yàn)證

　　if (!validateValue( xxx )) return

　　// 提交到服務(wù)器

　　sendAjax()

　　})

　　這樣一來，只要我們給函數(shù)寫好注釋，那么后期的時(shí)候，哪里出現(xiàn)問題，我們可以快速準(zhǔn)確的定位問題所在位置

　　十五、尊重對(duì)象所有權(quán)

　　· JavaScript 的動(dòng)態(tài)天性決定了沒有什么是不能修改的

　　· 從代碼層面出發(fā)，我們可以修改任何內(nèi)容，包括向 Object 的 prototype 上擴(kuò)展一些方法,，向 Array 的 prototype 上擴(kuò)展一些方法

　　· 但是在真實(shí)的企業(yè)級(jí)開發(fā)過程中，我們要絕對(duì)的尊重每一個(gè)對(duì)象的所有權(quán)

　　不要修改任何不屬于你的代碼，如果某一個(gè)對(duì)象不是由你負(fù)責(zé)創(chuàng)建或者維護(hù)，那么你也不要修改他的構(gòu)造函數(shù)

　　在好久好久以前：

　　我接觸過一個(gè)叫做 prototype 的第三方庫

　　它里面向 document 對(duì)象上擴(kuò)展了一個(gè)叫做 getElementsByClassName 的方法

　　是不是看起來很無聊，但是在沒有 getElementsByClassName 的年代，確實(shí)很好用

　　并且，擴(kuò)展的這個(gè) getElementsByClassName 方法的返回值是一個(gè) Array 并不是我們后來使用的 NodeList

　　而且還在實(shí)例身上擴(kuò)展了一個(gè)叫做 each() 的方法，專門用來遍歷

　　我們用起來的時(shí)候就會(huì)很方便

　　document.getElementsByClassName('item').each()

　　這個(gè)很好，而且對(duì)代碼開發(fā)進(jìn)行了簡(jiǎn)化

　　但是，一旦瀏覽器廠商開始支持這個(gè)方法了，那么你的方法就會(huì)出現(xiàn)問題了

　　后來，在所有瀏覽器廠商都支持了 getElementsByClassName 以后

　　當(dāng)在使用這個(gè)方法的時(shí)候，因?yàn)楹驮闹孛?/p>

　　會(huì)出現(xiàn)代碼的大面積報(bào)錯(cuò)

　　這個(gè)就是尊重代碼所有權(quán)

　　因?yàn)槟悴恢罏g覽器廠商什么時(shí)候會(huì) 告知 或 不告知 的更新一些內(nèi)容，或者修改一些 API

　　所以，不要修改任何不屬于你的內(nèi)容

　　十六、盡量不聲明全局變量

　　和尊重對(duì)象所有權(quán)有密切關(guān)系的就是盡可能少的聲明全局變量

　　拋開變量污染的層面不說，我們的每一個(gè)全局變量其實(shí)都是在向 window 上添加成員

　　var name = 'Jack'

　　function getInfo() { ... }

　　這都是全局變量，用起來也沒什么問題

　　但是也確實(shí)是在 window 上掛載了兩個(gè)名字

　　我們?cè)陂_發(fā)自己的代碼的時(shí)候, 盡可能的在全局制作一個(gè)命名空間，然后把我們所有需要的內(nèi)容全部放在里面

　　var myApp = {

　　name: 'jack',

　　getInfo () { ... }

　　}

　　這樣一來, 我們只是向 window 上掛載了一個(gè) myApp

　　剩下的所有東西都在我自己的命名空間里面

　　一旦出現(xiàn)問題，你能準(zhǔn)確的知道是你自己定義的變量或者方法出現(xiàn)了問題，還是原生的變量或者方法出現(xiàn)了問題

　　這個(gè)也是前端從沒有模塊化到模塊化開發(fā)的演變過程的原始階段：

　　o 獨(dú)立命名空間

　　o IIFE

　　o AMD / CMD

　　o CommonJS

　　o ES6 模塊化

　　十七、習(xí)慣使用常量

　　我們?cè)陂_發(fā)的過程中，經(jīng)常要使用一些變量來操作某些內(nèi)容

　　o 任何出現(xiàn)一次以上的內(nèi)容，都應(yīng)該提取出來變成一個(gè)常量的定義

　　o 任何一個(gè)需要顯示給用戶看到的文本內(nèi)容，都應(yīng)該提取出來變成一個(gè)常量

　　o 任何一個(gè)變量，在定義的時(shí)候都要考慮，將來會(huì)不會(huì)發(fā)生變化，如果不發(fā)生變化，那么就直接定義成常量

　　o 包括我們?cè)诓僮饕恍╊惷臅r(shí)候，應(yīng)該把這些類名提取出來做成常量，然后統(tǒng)一操作

　　這樣一來，我們可以避免因?yàn)椴恍⌒男薷淖兞慷鴮?dǎo)致出現(xiàn)的問題，也可以在代碼的各個(gè)部分保證代碼數(shù)據(jù)的統(tǒng)一，避免一個(gè)東西這里修改了，那里沒有修改的問題