每個程序員都有難以容忍的事情，比如用空格代替Tab做代碼格式化、大括號位置和空格縮進等。

這種事情很讓人煩惱但也不難以修改，下面是一些可以導致深層問題的情況：

• 空catch塊常常意味著代碼邏輯的缺失，即程序員明知道代碼可能出錯卻沒有采取任何措施。
• 無意義的命名說明代碼缺乏清晰可讀性，變量名類名方法名等應該能夠顧名思義而不是令人匪夷所思。
• 明顯重復的代碼塊早晚會出現問題，修改往往不能同步。
• 擁擠、難以理解的代碼通常難以維護。
• 通常來說，如果單一方法或函數的代碼量達到數百行，一般就違反了單一職責原則，會給代碼維護帶來問題。
• 無意義的代碼注釋只會浪費篇幅，代碼本身就已經告訴你如何完成的了，代碼注釋只是告訴你為什么要這么做。
• 莫名其妙的幻數是理解代碼的主要障礙，有意義的常量可以解決這個問題。
• 每個編譯器警告都是一個潛在的Bug，應該在出問題前修復它。
• 無意義的冗余代碼通常說明軟件的設計思路不清晰。
• 如果一段代碼和項目中的其他代碼明顯不一致，那肯定是犯了某種錯誤。
• 一連串的if-then-else可或者switch-case可以用字典代替，后者更為清晰。
• 不可測試的代碼一般是結構不良造成的，違反SOLID原則。

總結

以上是生活随笔為你收集整理的【软件质量】代码评审“亮红灯”的情况的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。