作為一個開發人員而言,寫代碼是工作的主要成份。我們不可否認,那些大神級的牛人寫出來的代碼確實要比那些剛出道的職場菜鳥寫出來的代碼要專業多了。這些不僅僅是工作經驗的原因,有些是一些編碼的習慣,有些是一些編碼的規范。說到底都是有規可循的,那么作為一個網站開發程序員,有哪些編碼規范需要注意,又有哪些原則必須遵守? 今天做網站小編就與你一起來分享一下。
原則一:單一的函數功能
這里需要解釋一下,所謂的單一函數功能,是指每個函數都負責單個功能的實現,把一些復雜的功能點拆分成多個函數的形式來組裝。這樣做有一個好處,一來可以使層次看起來更清晰,二來對后期的調試代碼而言也能夠定位的更加準確,哪個功能點出了問題,直接定位到某個函數去即可。另外,復雜的功能點拆分成多個函數更中利于單元測試。我們看下以下的例子:
未優化的代碼:

優化后的代碼:


優化后的代碼:

原則二:最小化嵌套
這里所謂的嵌套其實是指我們常用的判斷語句if, else 。具開發權威指出:過分深層的縮進,或者“嵌套”已經困擾了計算機界達幾十年之久,而且至今仍然是產生混亂代碼的罪魁禍首之一。Noam Chomsky 和 Gerald Weinberg 做過一份研究表明,很少有人能夠理解超過 3 層的嵌套 (Yourdon 1986a),很多研究人員建議避免使用超過 3 層的嵌套。如以下案例:
未優化的代碼:

優化后的代碼:

優化后的代碼:
以衛語句取代嵌套條件表達式是最少化嵌套的精髓之一。衛語句可以把我們的視線從異常處理中解放出來,集中精力到正常處理的代碼中。
簡化復雜的 if else 語句,基本就是三個關鍵:
針對頭重腳輕的 if else,盡早使用 return 返回,從而減少嵌套層次;
合并分支。有些分支持執行的內容相同,可以合并成為一個分支;
扁平化。下面這個例子就是扁平化最好的示例:


原則三:條件表達式盡可能清晰簡單
未優化的代碼:


優化后的代碼:
原則四:善用輔助類拆分
前面講的三個原則都是在討論如何編寫良好的函數,編寫良好易讀的代碼行和代碼塊,現在我們來把注意力放在代碼組織的更高層面,這一部分將涉及到軟件設計中最重要的能力——類的職責分配問題。如果你編寫的類有幾十個甚至上百個方法,或上千行代碼,一般都說明這個類設計上有問題了。
類就和人一樣,職責多的類就像領導,領導需要秘書和助理,因為秘書和助理能幫助領導從瑣事中解放出來。巨型類也一樣,也需要輔助類把與主業務邏輯無關的事移除出去。
那么怎么拆呢?
一般不產生數據的函數,不修改數據的函數,或有輸入就有明確輸出的函數,不和外部對象交互的函數都可以拆。


總結:
記得有一句話說得好:紳士的演講,應該像女人的裙子,越短越好! 那么,我們理解函數的時間也應該是越短越好。做網站小編個人覺得一開始寫代碼允許出現上述的那些未優化的代碼,因為代碼是一遍遍修改出來的。允許先寫骯臟的代碼,但必須要重構它。