程式碼規範怎麼做？今天來談一談

程式碼規範這東西網上很容易百度到一堆，除了天下文章一大抄的問題，另外，多數只給了結果，原因沒有充分說明，或者非常的糾結於大寫小寫，一個函式可以寫幾行的細節。感覺有點容易讓新人誤入歧途。

於是鍋叔打算根據自己的經驗分析下這些規範產生的原因，幫助新人深入理解為什麼這麼規定，知其然並知其所以然。

一、“程式碼規範”的由來

工作中如果你沒怎麼接手過其他同學的程式碼，那肯定會比接手過離職同學的程式碼，經常幫其他同學排查Bug的“大牛”們對

程式碼可維護性

的理解，要差上一個數量級。

如果你沒怎麼參與過一個持續存在3-5年以上，需求變更頻繁的系統模組的迭代開發，你也不容易理解，

程式碼重構

對於一個稍作修改，就Bug此起彼伏的模組質量改善的重要意義。

對軟體的迭代效率和質量負責任的人通常就是Team Leader，PM，這類第一責任人，他們深思熟慮一番後，得出一個重要結論，上面這些難於交接，修改困難，Bug橫行的坑，很大程度上都跟程式碼寫的不

規範

有關，因此就編寫了

程式碼規範。

　　二、程式碼規範作用

程式設計師的本質也是個手藝人，與大部分其他行業的施工規範的作用相似，主要是作用是

1。 避免造成施工缺陷，提供施工質量。

2。 方便同行交流，以便後期維護。

舉個例子，鍋叔家中近來正好在裝修，因為不是從毛坯重頭裝修的，這樣一些水電的走線情況就不是很清楚了，是裝修前已經施工完畢的。理論上開關插座線路是可以隨意的鋪設的，只要聯通就可以，可以一會兒排成一字，一會兒排成人字。這時比如你需要在牆上掛一副畫或者鏡子，需要在牆上打孔固定，那這個孔會不會打穿牆內的水電線就非常隨緣了。安裝師傅只能根據佈線規範和經驗判斷，一般的電線佈線在牆面是橫平豎直的，不會斜著來，或者轉圈圈，水管一般走天或者走地。你也就只能祈求之前施工的水電師傅是遵循這個規範來的，如果他走線很有個性導致你打壞了線路要重新維修，你一定會在心裡問候他的。

三、程式碼規範的內容

實踐中程式碼規範的內容很多團隊應該是“借鑑”來的。鍋叔其實建議，借鑑了之後，還要重視後期的調整，補充。每個團隊的技術棧，專案特點會有不同，在程式設計上的關注點也會對應不同。程式碼評審不應簡單的以規範為準，而應該以提高可維護為目的。評審中發現而未在程式碼規範中包含的內容，要及時增補。同時評審時還要注意傳達規範的目的，而不僅是讓大家機械遵守。

下面是一些鍋叔覺得比較常見重要的，做一下簡單解釋說明，排名不分先後 。

　　1. 不要使用魔法數字

可讀性，自己體會

if（deviceState == 1）{ doSomeThing（）； }//對比if（deviceState == DEVICE_STATE_ON）{ doSomeThing（）； }

　　2. 方法不要太長，注意分層，隱藏細節

合理分層，自行體會

function A（）{ 買菜（）； 備菜（）； 炒菜（）；}

vs

function B（）{ ……

下樓； 開啟車門； 按下點火開關； 打左轉向燈；

鳴笛； 開出車位；

如果遇到隔壁老王就打個招呼； 出小區右轉；

第二個十字路口左轉； 進菜市場左轉第一個攤位，買兩斤黃瓜； 拿上黃瓜，步行回車上；

掃碼交車費；…………}

　　3. 變數，方法命名要有準確含義

function A（）{ if（a == 1）{ B（）； }else{ C（）； } } //VSfunction 送禮物（）{ if（使用者性別 == 男）{ 送茅臺（）； }else{ 送古馳（）； } }

　　4. 無效的邏輯要及時清理

懶得舉例了，自行體會

　　5. 方法的功能應當與命名對應，不做超出命名範圍的動作

送禮物 方法，做了他命名之外的事，很容易被呼叫的人錯誤使用

function 收禮不辦事舉報（）{ 送禮物（）； if（不辦事 並且 不是我乾爹）{ 舉報他（）； }}//VS function 送禮物（）{ if（使用者性別 == 男）{ 送茅臺（）； }else{ 送古馳（）； } if（不辦事）{ 舉報他（）； } }

　　6. 使用者操作的錯誤，要確保有錯誤反饋。

典型的如沒有資料和發生錯誤，無法返回資料是不同情況，要加以區別。

　 7. 系統錯誤應當有日誌

錯誤要寫日誌， 不至於死無對證。。-_-||

　　8. 耗時操作要介面進行非同步等待處理　

讓使用者知道，現在正在處理，不是系統故障了。

　　#FormatImgID_11#

　　9. 業務列表查詢需要進行分頁處理

當資料記錄上億時，一次全部取出，放入記憶體，可能會使伺服器宕機……

10. ………………

作者：

鍋叔

原文連結：

https：//www。cnblogs。com/uncleguo/p/16143561。html