【软件质量】代码评审“亮红灯”的情况
生活随笔
收集整理的這篇文章主要介紹了
【软件质量】代码评审“亮红灯”的情况
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
每個程序員都有難以容忍的事情,比如用空格代替Tab做代碼格式化、大括號位置和空格縮進等。
這種事情很讓人煩惱但也不難以修改,下面是一些可以導致深層問題的情況:
- 空catch塊常常意味著代碼邏輯的缺失,即程序員明知道代碼可能出錯卻沒有采取任何措施。
- 無意義的命名說明代碼缺乏清晰可讀性,變量名類名方法名等應該能夠顧名思義而不是令人匪夷所思。
- 明顯重復的代碼塊早晚會出現(xiàn)問題,修改往往不能同步。
- 擁擠、難以理解的代碼通常難以維護。
- 通常來說,如果單一方法或函數(shù)的代碼量達到數(shù)百行,一般就違反了單一職責原則,會給代碼維護帶來問題。
- 無意義的代碼注釋只會浪費篇幅,代碼本身就已經(jīng)告訴你如何完成的了,代碼注釋只是告訴你為什么要這么做。
- 莫名其妙的幻數(shù)是理解代碼的主要障礙,有意義的常量可以解決這個問題。
- 每個編譯器警告都是一個潛在的Bug,應該在出問題前修復它。
- 無意義的冗余代碼通常說明軟件的設計思路不清晰。
- 如果一段代碼和項目中的其他代碼明顯不一致,那肯定是犯了某種錯誤。
- 一連串的if-then-else可或者switch-case可以用字典代替,后者更為清晰。
- 不可測試的代碼一般是結構不良造成的,違反SOLID原則。
總結
以上是生活随笔為你收集整理的【软件质量】代码评审“亮红灯”的情况的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ehlib中dbgrideh的多选框设置
- 下一篇: 访问DBGRIDEH中的行与列