談起代碼質量，可讀性，可維護性等，總是說，我們要有一套代碼規范來嚴格執行。我經歷的公司，大多都有代碼規范，至於最終代碼規范有沒有發揮作用么，你猜……
代碼規范從制定到實施到發揮作用，其實還是有很多小的細節，今天我就來說說我看到的一些細節。
代碼規范的本身的問題
從規范目標細節的角度，代碼規范分為：
- 注釋
- 命名
- 縮進空格
- 語句格式
- 規模
- 可靠性
- 語言特殊項
代碼規范從實施的角度，我分了幾類：
- 簡單易執行
命名、注釋就是簡單易執行
- 一般可執行
操作符＋＋和— —操作符的應用是否符合規范？
只讀不可寫的常量加上readonly或者const
- 有難度自行掌控
一屏原則：一個方法體的代碼幅應該在一屏比較和合理；邏輯復雜的代碼可以抽離出方法體；
int的返回值是否合理？（負值為失敗，非負值成功）
- 強迫症規范
很多關於空格類的規范，就屬於強迫症規范
@Class的寫法
寫法模板：@class class1, class2;
建議的寫法
1 |
@class UIView, UIImage; |
不建議的寫法
1 |
@class UIPress; |
以上的規范，純屬編寫規范的人的個人喜好，寫法上我覺得沒有對錯，有一些過線。
5.關於特定語言或者數據庫的編碼特殊限定需求
例如：進行equal判斷時，倒着寫的規范：
if(“true”.equals(isLogin)){return true;}
用StringBuffer代替String；用Stringbulider代替StringBuffer；
網上我還是看了不少的規范，真的好的規范不多。代碼規范一般會由團隊里資深的程序員來制定，制定的方法一般是網上找一個基本的Base版，再做增減。專業的事交給專業的人來做，代碼規范的制定應該由在一線摸爬滾打很多年的程序員主導，由多人參與共同制定，牽頭人最好是做過很多大項目，有多年編程經驗，為人謙虛，並一直保持學習狀態的全棧工程師。
一個好的代碼規范，必須由所有的團隊成員一起認同，共同來維護，而不是由制定的人，來負責推廣監督執行。在一開始制定的時候，就要充分的聽取各方的意見，達成一致。有的代碼規范太細，在寫代碼的時候，沒法細摳，在事后也沒有機會review，與其不能執行，不如簡化些，更接地氣。有的代碼規范太抽象，例如函數規模，代碼規模等，還是要有可量化標准，可執行的方法，最好能有工具支持，例如寫代碼時的提示，編譯代碼前的格式自動檢查等等。
代碼規范的養成，習慣比規范更重要
代碼規范除了制定，其實更注重每個程序員的執行。程序員每天寫代碼的時候更規范，當然會比之后再review代碼，再整理代碼做的好的多。而寫代碼時的控制，更多的是一種習慣。代碼規范前幾條里必然有命名，縮進等，這些每天寫代碼的基本，必然是每個程序員的習慣，而不是時刻掛在腦子里，要想一下的東西。就像前端程序員寫html的時候，一定會注意封閉性，寫一個<div></div>一定成對出現。
對於剛開始寫代碼的小白來說，只要寫一段時間的代碼，習慣也會慢慢養成。這種養成是IDE協助下的養成。或者說，養成了IDE建議我們的習慣。舉例說，JAVA的eclipse協助生成get;set;的代碼，默認的會有setApplicationId這樣的大小寫習慣，會有{在前一行最后的默認習慣
1 |
for(int i=0;i<max;i++){ |
而同樣的，C#的著名IDE Visual Studio就會幫.Net程序員養成，{}分行的習慣（默認配置是這樣的）
1 |
for(int i=0;i<max;i++) |
漸漸的，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的重要抓手。
附件
什么樣的代碼規范才能得到程序員的認可？
http://www.cocoachina.com/programmer/20180327/22782.html
關於代碼規范的一些參考
https://blog.csdn.net/mengdonghui123456/article/details/68066766
這可能是史上最全的Android代碼規范
https://www.jianshu.com/p/f5a55dff62f0
阿里巴巴java代碼規范
https://github.com/alibaba/p3c/blob/master/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C%EF%BC%88%E8%AF%A6%E5%B0%BD%E7%89%88%EF%BC%89.pdf