程式碼規範淺談

鍋叔發表於2022-04-15

　　

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

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

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

　　工作中如果你沒怎麼接手過其他同學的程式碼，那肯定會比接手過離職同學的程式碼，經常幫其他同學排查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. ………………

 

相關文章