好的代碼必定是整潔的，而且可以幫助閱讀的人快速理解和定位。好的代碼能夠加快應用的開發迭代速度，沒必要花過多的時間來修復 bug 和完善代碼。好的代碼不但可以使得新的項目成員更容易加入項目，同時方便項目組成員快速作好 Back up。好的代碼便於促進團隊間交流合做提高開發效率。java
代碼質量評價標準python
有編碼經驗的人對代碼都有必定的「鑑賞力」，可以憑感受給出代碼好壞的主觀評價。可是這種憑感受的方式太過個性隨意，所謂仁者見仁智者見智，很難達成共識，那有沒有一種公認的標準來鑑定代碼質量呢？c++
答案是有的。這裏簡單分享當下較經常使用的評價標準，其中包括：編碼規範、可讀性、可維護性、重複度及可測試性。git
編碼規範github
主要包含是否遵照了最佳實踐和團隊編碼規範，是否包含可能出問題的代碼，以及可能存在安全的漏洞。編碼規範有助於提升團隊內協助的效率以及代碼的可維護性。shell
可讀性npm
Code Review 是一個很好的測驗代碼可讀性的手段。若是你的同事能夠輕鬆地讀懂你寫的代碼，那說明你的代碼可讀性很好；反之則說明你的代碼可讀性有待提升了。遵照編碼規範也能讓咱們寫出可讀性更好的代碼。編程
可維護性安全
代碼的可維護性是由不少因素協同做用的結果。代碼的可讀性好、簡潔、可擴展性好，就會使得代碼易維護；更細化地講，若是代碼分層清晰、模塊化好、高內聚低耦合、聽從基於接口而非實現編程的設計原則等等，那就可能意味着代碼易維護。除此以外，代碼的易維護性還跟項目代碼量的多少、業務的複雜程度、利用到的技術的複雜程度、文檔是否全面等諸多因素有關。微信
重複度
遵照 Don’t Repeat Yourself 原則，儘可能減小重複代碼的編寫，複用已有的代碼。對項目按期進行代碼重複度檢測是一個頗有意義的事，能夠幫助開發人員發現冗餘代碼，進行代碼抽象和重構。重複的代碼一旦出錯，意味着加倍的工做量和持續的不可控。若是代碼中有大量的重複代碼，就要考慮將重複的代碼提取出來，封裝成公共的方法或者組件。
可測試性
代碼可測試性的好壞，一樣能夠反應代碼質量的好壞。代碼的可測試性差，比較難寫單元測試，那基本上就能說明代碼設計得有問題。
除此以外還有不少代碼質量評價標準。咱們須要一些取捨，選取部分你們有共識的規則定義團隊好的代碼標準。
代碼質量維度
當前版本經過 @iceworks/doctor 從 5 個維度對代碼進行評分：
最佳實踐：經過 @iceworks/eslint-plugin-best-practices 分析項目，提出符合當前工程特徵（對 ice 和 Rax項目友好）的最佳實踐及阻塞問題發佈卡口，幫助開發者優化項目性能，避免潛在 bug 。
安全實踐：經過 @iceworks/eslint-plugin-security-practices 掃碼代碼檢測工程中可能存在的安全風險，包含 url 、敏感成詞、明文帳密信息及 npm 包證書檢測，下降項目安全風險，守衛項目安全。
阿里代碼規範：這一維度主要反饋開發人員對於 eslint-config-ali 阿里開發規約的遵照程度。
可維護度：經過 typhonjs-escomplex 對文件進行掃碼，得出每一個文件的可維護度，可讀性及複雜度評分。針對得分較差的文件能夠進行深度分析幫助開發者更好的重構複雜代碼。
重複度：經過 jscpd 計算重複出現的代碼區塊佔比，計算出 clone 分數。並逐一列舉重複的代碼，方便開發者快速定位重複代碼，將其封裝成公共的方法或者組件。
根據上述 5 個維度經過加權平均的方式計算項目質量分，並根據木桶效應，在計算得分的過程當中加大了最低分的權重，得出最終項目質量評分。
項目地址
github地址：https://github.com/ice-lab/iceworks/tree/master/
推薦幾款代碼質量檢測工具:
而後說說工具的問題。我用過的開源、商業代碼質量工具沒少說也有個二三十種（ V 站除了同行應該沒人比我多了。。。吧）。這些工具若是按照規則類型劃分，能夠看作兩類。一類安全，也就是檢查安全問題，好比 NullPointer、SQL Injection、Data Race，他們會影響程序的安全運行；一類是規約，簡單來講就是 code style。不過考慮到不少規則其實二者兼具，我就簡單的按語言劃分好了。（都是開源的）
c/c++：
clang-tidy http://clang.llvm.org/extra/clang-tidy
CSA https://clang-analyzer.llvm.org
cppcheck https://github.com/danmar/cppcheck
cpplint https://github.com/google/styleguide
phasar https://github.com/secure-software-engineering/phasar
這裏面比較推薦 clang-tidy，雖然規則很少，可是規則編寫簡單，只要你對 C++有足夠了解，能夠定製出十分豐富的內容
java:
google-java-format https://github.com/google/google-java-format
find-sec-bugs https://find-sec-bugs.github.io
spotbugs https://spotbugs.github.io
pmd https://github.com/pmd/pmd
p3c https://github.com/alibaba/p3c
soot https://sable.github.io/soot
spotbugs 和 pmd 都是比較優秀的工具，前者有 find-sec-bugs 這樣的插件。然後者，ali 的 p3c 規則集就是基於 pmd 實現的。此外 pmd 是一個針對多種語言的框架，內容十分豐富。這二者國際化和文檔都作的很是好。而 soot 本質上一個 jvm bytecode 的優化框架，但一樣能夠基於此作出各類工具，不過考慮到它複雜的內容，emmmm...
其餘：
python https://github.com/PyCQA/pylint
kotlin https://github.com/arturbosch/detekt
JS/TS https://github.com/eslint/eslint
Rust https://github.com/rust-lang/rust-clippy
shell https://github.com/koalaman/shellcheck
Multiple languages https://github.com/facebook/infer
Multiple languages https://github.com/github/semantic
我列舉的都是我以爲有用的而且目前處於活躍狀態的項目，你們無聊的話能夠看看。還有一個專門介紹靜態分析工具的倉庫https://github.com/mre/awesome-static-analysis
再而後對於工具的使用。對於工具你們都知道，不用等於沒用。因此通常的解決辦法都是融入流程，最簡單的像 Unittest 同樣，編譯完成後跑一遍。併入 CI 流程也是廣泛作法，代碼入庫前掃描成功才容許合併，這樣同時還能夠保證 code format 的問題。除此以外，減小這類工具的 report 數量也是重點。過於繁多的報告（尤爲是項目早期開發的時候）每每不利於發現真正有價值的問題，也不利於修復。因此熟悉工具的規則和配置，少報無關問題是工具使用的關鍵。
簡單說就這麼多，若是感興趣我有空能夠開個系列，專門介紹代碼靜態分析的技術、使用問題
號稱中國最好的靜態分析工具（未來就是世界最好）
https://www.sourcebrella.com/
對標國際廠商好比 Coverity、fortify、checkmax，咱們一點不虛，甚至在技術上還有優點（ PLDI、ICSE 最近幾年都有論文）
本文分享自微信公衆號 - 肉眼品世界（find_world_fine）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。