給C#開發者的程式碼審查清單
這是為C#開發者準備的通用性程式碼審查清單,可以當做開發過程中的參考。這是為了確保在編碼過程中,大部分通用編碼指導原則都能注意到。對於新手和缺乏經驗(0到3年工作經驗)的開發者,參考這份清單編碼會很幫助。
清單
1. 確保沒有任何警告(warnings)。
2.如果先執行Code Analysis(啟用所有Microsoft Rules)再消除所有警告就更好了。
3. 去掉所有沒有用到的usings。編碼過程中去掉多餘程式碼是個好習慣。(參考:msdn)
4. 在合理的地方檢查物件是否為’null’,避免執行的時候出現Null Reference Exception。
5. 始終遵循命名規範。一般而言變數引數使用駝峰命名法,方法名和類名使用Pascal命名法。(參考:msdn)
6. 請確保你瞭解SOLID原則。
根據維基百科定義:在程式設計領域,SOLID (單一功能、開閉原則、里氏替換、介面隔離以及依賴反轉) 是由羅伯特·C·馬丁在21世紀早期引入的記憶術首字母縮略字,指代了物件導向程式設計和麵向物件設計的五個基本原則。當這些原則被一起應用時,它們使得一個程式設計師開發一個容易進行軟體維護和擴充套件的系統變得更加可能。SOLID所包含的原則是通過引發程式設計者進行軟體原始碼的程式碼重構進行軟體的程式碼異味清掃,從而使得軟體清晰可讀以及可擴充套件時可以應用的指南。SOLID被典型的應用在測試驅動開發上,並且是敏捷開發以及自適應軟體開發的基本原則的重要組成部分。參考:wiki/SOLID_(物件導向設計)
7. 程式碼可重用性:如果一塊程式碼已經被使用超過一次,或者你希望將來使用它,請提取成一個方法。將重複的工作做成通用的方法放在相關的類中,這樣一旦你完成別人就可以使用了。將常用功能開發成使用者控制元件,這樣可以跨專案重用它們。(參考:① 、 ②)
8. 程式碼一致性:比方說,Int32寫成int,String寫成string,應該在程式碼裡保持統一形式。不能一會二寫成int一會兒寫成Int32。
9. 程式碼可讀性:程式碼應該是可維護的,便於其他開發者理解。(參考:msdn)
10. 釋放非託管資源,比如檔案I/O,網路資源等。一旦使用結束就應該釋放它們。如果你想一旦超出使用範圍就自動釋放物件,可以使用usings將非託管程式碼括起來。參考:msdn
11. 合理實現異常處理(try/catch和finally塊)和異常記錄。參考:msdn
12. 確保程式碼中方法的行數不要過多,不超過30到40行。
13. 及時用程式碼管理工具check-in/check-out程式碼。(比如TFS) 參考:codeproject.com
14. 相互審查程式碼:和你的同事交換程式碼,實現內部審查。
15. 單元測試:編寫開發測試用例完成單元測試,確保程式碼被送到QA以前,基本測試完成。參考:msdn
16. 儘量避免for/foreach迴圈巢狀和if條件巢狀。
17. 如果程式碼只會使用一次,請使用匿名型別。參考:msdn
18. 儘量使用LINQ查詢和Lambda表示式,增加可讀性。參考:msdn
19. 合理使用var、object和dynamic關鍵字。由於很多開發者會感到困惑或者知道的很少,會覺得它們有些相似,故而交換使用,這是要避免的。參考:blogs.msdn
20. 使用訪問限定符(private, public, protected, internal, protected internal)限定每個方法、類或變數的需要範圍。比方說如果一個類只會在程式集內使用,那麼定義成internal就足夠了。參考:msdn
21. 在需要保持解耦的地方使用介面,有些設計模式的出現也是由於介面的使用。參考:msdn
22. 按照用法和需要將類定義為sealed、static或abstract。參考:msdn
23. 如果需要多次串聯,請使用Stringbuilder代替string,這可以節省堆記憶體。
24. 檢查是否有不可能執行的程式碼,如果有,請修改。
25. 在每個方法前註釋,說明它的用法、輸入型別和返回值型別資訊。
26. 使用類似Silverlight Spy的工具,檢查和操控Silverlight應用在執行時對XMAL的渲染,以此來改善效率。這可以在設計執行XAML時,節省大量退回和來回修改的時間。
27. 使用filddler工具通過檢查HTTP/網路流量和頻寬,來跟蹤web應用和服務的效能。
28. 如果你想確認Visual Studio以外的方法,請使用WCFTestClient.exe工具,或者裝載它的程式到Visual Studio來進行除錯。
29. 在任何合理的地方使用constants和readonly。參考:/msdn、msdn
30. 儘量避免強制轉換和型別轉換,因為會造成效能損失。參考:msdn
31. 對於你想提供自定義資訊的類,請過載ToString(來自Object類)。參考:msdn
32. 避免直接從其他程式碼中ctrl+c/ctrl+v。一直建議還是自己用手敲,即使你已經找到相關程式碼。這樣可以鍛鍊自己寫程式碼能力,還能正確理解那段程式碼的用法。最終你永遠都不會忘記那段程式碼。
33. 保持閱讀書籍和文章的良好習慣,遵循大神們的實踐指導。(比如微軟專家和一些著名的專家,Martin Fowler, Kent Beck, Jeffrey Ritcher, Ward Cunningham, Scott Hanselman, Scott Guthrie, Donald E Knuth.)
34. 確認程式碼是否有記憶體洩漏。如果有,請確保已修正。參考:blogs.msdn.com
35. 儘可能參加專家們組織的技術研討會,可以接觸到最新的軟體趨勢、技術和最佳實踐
36. 要透徹理解OOP概念,並儘可能在程式碼裡實現。
37. 知道專案設計架構,可以從整體上理解程式的執行流程。
38. 採取必要措施阻止避免任何交叉指令碼攻擊、SQL隱碼攻擊和其他安全漏洞。
39. 永遠記得將保密和敏感資訊加密(通過使用好的加密演算法),比如儲存到資料庫的密碼和儲存在web.config檔案中的連線字元,要避免被非認證的使用者操縱。
40. 避免對已知型別(原始型別)使用預設關鍵字,比如int, decimal, bool等。多數情況下,如果不確定是值型別還是引用型別,就使用泛型型別(T)。參考:msdn
41. 微軟(在程式碼分析條例和指導中)並不推薦使用’out’和’ref’,這些關鍵字是通過引用傳參,請注意,’ref’引數在傳入被呼叫方法之前,應當在呼叫方法中先初始化,但’out’引數就不是這樣。參考:msdn
相關文章
- 給 C# 開發者的程式碼審查清單C#
- 程式碼審查清單可消除更多的bug
- 程式碼審查清單:Java併發 - Roman LeventovJava
- 構建有效的程式碼審查清單需要注意哪些事項?
- 【審視】Scrum Master的檢查清單ScrumAST
- 開發者眼中的程式碼審查“真相”
- Web開發者必備:Web應用檢查清單Web
- 程式碼複審——給結對程式設計的小夥伴程式設計
- 程式碼審查(Code Review)清單View
- 京東雲開發者|程式碼評審的價值和規範
- 接手資料庫的檢查清單資料庫
- 順序審批流的簡單程式碼實現
- 前端團隊程式碼評審 CheckList 清單前端
- 寓教於樂 給程式碼審查者的幾點建議
- 程式設計師必備的程式碼審查(Code Review)清單程式設計師View
- 程式碼互審
- 程式碼審查
- 程式碼複審
- 【轉】程式設計師必備的程式碼審查(Code Review)清單程式設計師View
- 線上故障的排查清單,運維拿走不謝!運維
- CSCMS程式碼審計
- PHP程式碼審計PHP
- 程式碼審查工具
- buu 程式碼審計
- 程式碼審查的重要性
- 什麼是程式碼審計?程式碼審計有什麼好處?
- 說透程式碼評審
- Graudit程式碼安全審計
- 程式碼審計————目錄
- aspx程式碼審計-2
- 程式碼審查過程
- 隊友程式碼複審
- 敏捷程式碼審查指南敏捷
- JFinalcms程式碼審計
- 程式碼審查或評審的最佳實踐 - FogBugz
- 哪些業務場景需要做程式碼審計?程式碼審計很重要嗎?
- 程式碼審計是什麼?程式碼審計操作流程分為幾步?
- MVC框架的程式碼審計小教程MVC框架