在上篇中我們看了一些關於代碼的規范問題，今天我們繼續來看一下還有哪些需要注意的地方
分離（松耦合）
在前端領域，我想大家對結構(html),表現(css)和行為(js)再熟悉不過了，從我們接觸前端的第一天就開始和這三大巨頭斗智斗勇翻雲覆雨，而今天我們要說的就是這三者之間的松耦合，為什么要進行松耦合呢，來，上個栗子
通過栗子我們可以看到結構表現和行為都被懟在了一起，那這樣寫能不能實現功能呢，是完全OK的，只不過看起來會非常的雜亂無章。如果我是你的同事，Believe me，I will kan le you 。我們要寫出規范的代碼一定要避免過度的耦合。不管是使用當前最火的React或Vue還是不使用框架，都不要將這三者耦合在一起，尤其是在協作開發當中，除非你能打的過同事！那樣的話你就可以隨心所欲為所欲為，否則還是乖乖的解開耦合吧
避免全局變量的使用
在寫代碼的過程中，盡量避免使用全局變量，因為大量的使用全局變量可能會引起以下三點：
1.不必要的代碼沖突
2.導致代碼非常脆弱，尤其是函數里面依賴了全局變量的時候
3.難以測試，會降低代碼的可測試性，因為我們會在生產測試等多個環境中切換，一旦代碼大量依賴全局變量，這就是大大增加我們測試的難度
在必須使用全局變量的情況下我們該怎么辦呢，我們可以把所有的全局變量都扔到一個單一的全局對象當中去，這也是YUI，JQuery都在使用的單全局變量模式，會減少我們代碼中出錯的概率。
當然我們能不使用全局變量就不要去使用全局變量，在當前各種模塊化組件化橫行的時代，我們應盡可能的使用內部的變量。要不然你定義幾個全局變量，每個同事再定義幾個全局變量，得了，代碼中隨處可見全局變量怎么能行呢。
關於傳參
在編程語言中傳參是避不開的話題，那我們該怎么樣規范的傳參呢，我總結了一下，只傳函數內部需要使用的參數進去，什么意思呢，我們來舉個例子
下面我們來看看比較規范的寫法
通常我會推薦第二種寫法，為什么呢，因為直接傳了使用的值進去，這樣能一眼看出函數想要的參數是什么，而第一種方法雖然沒有代碼上的錯誤，但是並不能一眼看出函數需要的參數是什么，只知道是把事件對象傳遞了進去，具體使用了事件對象上的哪個函數並不能在調用時一眼看出。當然第一種也是有點好處的，比如調用更方便，可以避免多次調用前都要對數據進行處理。但是相比之下，第二種會更加有優勢。在框架中我們寫組件時也要盡量保持這個規范，假設你直接一個對象全部傳進去了，當同事要復用你的組件的時候就爽了，他一眼看去根本不知道你組件需要傳遞哪些屬性，分分鍾就有錘你的沖動！
好啦好啦這篇就到這里啦，是時候打開冰箱擼一瓶肥宅快樂水了
