再談談代碼規範的事

時間 2019-11-16

標籤談談代碼規範简体版

原文原文鏈接

談起代碼質量，可讀性，可維護性等，老是說，咱們要有一套代碼規範來嚴格執行。我經歷的公司，大多都有代碼規範，至於最終代碼規範有沒有發揮做用麼，你猜……
代碼規範從制定到實施到發揮做用，其實仍是有不少小的細節，今天我就來講說我看到的一些細節。html

代碼規範的自己的問題

從規範目標細節的角度，代碼規範分爲：前端

註釋
命名
縮進空格
語句格式
規模
可靠性
語言特殊項

代碼規範從實施的角度，我分了幾類：java

簡單易執行
命名、註釋就是簡單易執行

通常可執行
操做符＋＋和— —操做符的應用是否符合規範？
只讀不可寫的常量加上readonly或者const

有難度自行掌控
一屏原則：一個方法體的代碼幅應該在一屏比較和合理；邏輯複雜的代碼能夠抽離出方法體；
int的返回值是否合理？（負值爲失敗，非負值成功）

強迫症規範
不少關於空格類的規範，就屬於強迫症規範

@Class的寫法
寫法模板：@class class1, class2;
建議的寫法git

1	@class UIView, UIImage;

不建議的寫法程序員

1 2	@class UIPress; @class UIPressesEvent;

以上的規範，純屬編寫規範的人的我的喜愛，寫法上我以爲沒有對錯，有一些過線。github

5.關於特定語言或者數據庫的編碼特殊限定需求
例如：進行equal判斷時，倒着寫的規範：
if(「true」.equals(isLogin)){return true;}
用StringBuffer代替String；用Stringbulider代替StringBuffer；數據庫

網上我仍是看了很多的規範，真的好的規範很少。代碼規範通常會由團隊裏資深的程序員來制定，制定的方法通常是網上找一個基本的Base版，再作增減。專業的事交給專業的人來作，代碼規範的制定應該由在一線摸爬滾打不少年的程序員主導，由多人蔘與共同制定，牽頭人最好是作過不少大項目，有多年編程經驗，爲人謙虛，並一直保持學習狀態的全棧工程師。編程

一個好的代碼規範，必須由全部的團隊成員一塊兒認同，共同來維護，而不是由制定的人，來負責推廣監督執行。在一開始制定的時候，就要充分的聽取各方的意見，達成一致。有的代碼規範太細，在寫代碼的時候，無法細摳，在過後也沒有機會review，與其不能執行，不如簡化些，更接地氣。有的代碼規範太抽象，例如函數規模，代碼規模等，仍是要有可量化標準，可執行的方法，最好能有工具支持，例如寫代碼時的提示，編譯代碼前的格式自動檢查等等。app

代碼規範的養成，習慣比規範更重要

代碼規範除了制定，其實更注重每一個程序員的執行。程序員天天寫代碼的時候更規範，固然會比以後再review代碼，再整理代碼作的好的多。而寫代碼時的控制，更多的是一種習慣。代碼規範前幾條裏必然有命名，縮進等，這些天天寫代碼的基本，必然是每一個程序員的習慣，而不是時刻掛在腦子裏，要想一下的東西。就像前端程序員寫html的時候，必定會注意封閉性，寫一個<div></div>必定成對出現。eclipse

對於剛開始寫代碼的小白來講，只要寫一段時間的代碼，習慣也會慢慢養成。這種養成是IDE協助下的養成。或者說，養成了IDE建議咱們的習慣。舉例說，JAVA的eclipse協助生成get;set;的代碼，默認的會有setApplicationId這樣的大小寫習慣，會有{在前一行最後的默認習慣

1
2
3

for(int i=0;i<max;i++){
 r[i]=0;
}

而一樣的，C#的著名IDE Visual Studio就會幫.Net程序員養成，{}分行的習慣（默認配置是這樣的）

for(int i=0;i<max;i++)
{
 r[i]=0;
}

漸漸的，IDE幫咱們區分了這個程序員是寫什麼代碼出身的，給程序員的代碼打上了不一樣種類的標準印記。有些左撇子在小時候，父母會強制他們用右手拿筷子吃飯，IDE的這種強制，對以後程序員的制定代碼規範也有深深的印記。他們會以爲，本身最熟悉的那種類型，那種習慣就是正確的。我看了不少語言的代碼規範後，發現這種IDE的習慣的影響力還真的是很強，也會影響到代碼規範的制定。

另外一方面，有的習慣是工具幫不了咱們的。例如代碼規模的控制，例若有野生程序員喜歡用拼音來命名。一些優秀程序員須要養成的習慣：

用合理命名的習慣
按期整理代碼的習慣->清理無用代碼->分割大段代碼爲更小的函數
註釋的習慣
寫文檔的習慣

固然好的習慣遠遠不止以上這些，好習慣就是每一個程序員的功底，內功，基礎越好的程序員，寫代碼的效率固然越高。

代碼規範的推行方式

IDE對於代碼規範的影響，從側面說明了另一個問題，代碼規範的推行問題。

我目前想到的代碼規範的推行方式，定製工具，培養習慣，code review。

據說，百度之前學Google的時候，也搞了一套相似的模式。新程序員入職的時候，要先學習代碼規範，而後學會整個編碼發佈的流程，其中就有自動化檢查代碼規範的流程，若是不經過，就回去繼續改，不能發佈。新程序員通常都要花上一兩天學習這套東西，不然工做永遠完成不了。這裏說的就是代碼規範的強制推行工具，幫助或者說限制程序員必需要按照制定的標準來。

學會使用統一的工具，統一開發環境或者IDE工具，使用統一的ESLint，JSLint配置。或者公司有統一的代碼規範檢查工具。

固然，有的規範能夠工具化，有的不能夠
例如大小寫問題，下劃線問題，每行長度問題，if後{}位置問題，空格的編寫等。單個函數不超過規定行數？縮進層數是否不超過規定？這些很容易用工具來檢查。
包裝類作簡單預算前是否保證非空？建議都使用包裝類。方法調用前是否有非空判斷？這些就沒這麼容易了。而前面舉例的一些自行掌控的規範，更是隻能看程序員的素質了。

代碼規範推行的最後一招，就是code review。具體分實時review，編寫後review，meeting review。實時是指結對編程的那種方式，編寫後是說Leader幫忙檢查代碼，meeting review的代價最大，一組人一塊兒審閱代碼。

代碼規範爲何難以推行？由於沒有自動化。規範的條條框框這麼多，隨時記在腦子裏，怎麼可能？不要期望程序員手工寫代碼的時候，能認真執行這些規則。從推行方式來看，IDE工具或者統一配置IDE工具的方式最簡單->定製代碼檢查和規範工具->培養程序員習慣->code review。而現實狀況見的最多的執行方案，是先安排我的制定一套規範，用代價最高的code review的方式來推行，幾回以後，你們都以爲性價比低而放棄了。一個好的代碼規範的推行，要更多的自動化，更早的在編寫過程當中處理問題。

代碼規範的其餘

代碼規範不該該作的事情
太細節的東西不要管，假設我告訴你天天出門先邁右腳會走好運，天天你能作的到嗎？例如，有看到過下面的規範要求，除
非IDE工具能夠自動幫我作到這些，我我的就以爲，管的有些太細。
屬於我的習慣的東西，不要強加在別人身上。但同一份代碼，多我的編寫，儘可能參照以前的風格。別讓後人看一份代碼的時候產生混亂的感受。
1
2
3
4
5
通常寫法
app_name="支付寶";

規範要求，爲了可讀性，先後須要加入空格
app_name = "支付寶";
代碼規範解決不了代碼腐化的問題
一個長期在維護的代碼，時間長了，不免出一些問題。例如需求的反覆變化，致使的代碼的雜亂，原先的需求是作一個貸款超市，過幾天需求變了，變成了信用卡超市，過幾天又變成了信用卡還款及記帳工具，這些並非代碼規範就能解決的。根本的處理方法是重構，或者新代碼的分割。

代碼規範也會與時俱進
技術更新很快，工程過程當中遇到的問題也是層出不窮，所以，代碼規範也不會是一招定論的，須要不斷地更新、補充、完善，這樣才能與時俱進，保持生命力。舉例說JAVA8中引入了Lambda表達式，對於半路出家的程序員，這種表達式若是寫的抽象一些，可讀性會出點問題的。有必要對於Lambda寫法上作必定的規範。還有如C#和js中引入的await和async的異步寫法，沒學過直接看代碼的時候，確實會發生不能理解的問題，說明尚未成熟規範寫法，也沒有深刻學習語法的時候，新技術經常會致使可讀性降低。

小結

一個技術團隊的氣質的重要表現就是團隊的代碼規範。一個阿里出來的程序員，以後寫出來的代碼，必然也會有以前的習慣，由於都是受過同一個代碼規範薰陶的，這就是團隊氣質的體現，每當看到小公司混亂代碼的時候，就會想大廠和小廠的不一樣。若是團隊的開發都帶有相同的氣質，這個團隊的統一性，戰鬥力就會是驚人的，外人看來，這就是團隊而不是寫代碼的個體了。代碼規範及其執行對於技術團隊十分的重要，制定好代碼規範，推行好代碼規範，持續的優化，會讓團隊的效率大大的提高，是每個技術團隊Leader的重要抓手。