代碼規范這東西網上很容易百度到一堆，除了天下文章一大抄的問題，另外，多數只給了結果，原因沒有充分說明，或者非常的糾結于大寫小寫，一個函式可以寫幾行的細節，感覺有點容易讓新人誤入歧途，
于是鍋叔打算根據自己的經驗分析下這些規范產生的原因，幫助新人深入理解為什么這么規定，知其然并知其所以然，
一、“代碼規范”的由來
作業中如果你沒怎么接手過其他同學的代碼，那肯定會比接手過離職同學的代碼，經常幫其他同學排查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(); } } //VS function 送禮物(){ if(用戶性別 == 男){ 送茅臺(); }else{ 送古馳(); } }
4. 無效的邏輯要及時清理
懶得舉例了，自行體會
5. 方法的功能應當與命名對應，不做超出命名范圍的動作
送禮物 方法，做了他命名之外的事，很容易被呼叫的人錯誤使用
function 收禮不辦事舉報(){ 送禮物(); if(不辦事 并且 不是我干爹){ 舉報他(); } } //VS function 送禮物(){ if(用戶性別 == 男){ 送茅臺(); }else{ 送古馳(); } if(不辦事){ 舉報他(); } }
6. 用戶操作的錯誤，要確保有錯誤反饋，
典型的如沒有資料和發生錯誤，無法回傳資料是不同情況，要加以區別，
7. 系統錯誤應當有日志
錯誤要寫日志， 不至于死無對證，，-_-||
8. 耗時操作要界面進行異步等待處理
讓用戶知道，現在正在處理，不是系統故障了，
9. 業務串列查詢需要進行分頁處理
當資料記錄上億時，一次全部取出，放入記憶體，可能會使服務器宕機……
10. ………………
本文來自博客園，作者：鍋叔
轉載請注明原文鏈接：https://www.cnblogs.com/uncleguo/p/16143561.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/458313.html
標籤：其他
上一篇：代碼規范淺談