我想開始測量Michael Feathers所稱的代碼紊亂,即

churn vs. complexity.

為此,我需要測量C或Java文件的復雜性.所以我發(fā)現(xiàn)了一些測量圈復雜度(CC)的工具.它們各自在功能或方法級別上很好地測量CC.但是,我需要一個文件級別的度量標準,并且它們在那里做得不好.一個工具只返回文件中所有方法復雜度的平均值,另一個工具將整個文件視為一個巨大的方法,即它計算整個文件中的所有決策點.

所以我做了一些研究,發(fā)現(xiàn)McCabe僅在模塊方面定義CC – 并且它們將模塊定義為函數 – 而不是文件(參見this presentation的幻燈片20和30).而且我認為這是有道理的.

所以現(xiàn)在我只想弄清楚如何表示文件的復雜性.我的想法是我應該使用該文件的最大方法CC.

有關該方法或任何其他建議的任何想法？

謝謝！

肯

最佳答案 幾年前我有同樣的問題.我用以下方式回答了它并且它完美地起作用并且對我有用：

最小化復雜性的目的是提高可維護性.循環(huán)復雜性是邏輯復雜性的指標,你是對的 – 它適用于最小的“單位”,即功能.可以推導出“總結”指標,例如總計/最大/最小/等,但是當涉及圈復雜度時,它們很少顯示有用的東西.我嘗試使用’summary’指標來比較2個代碼庫,但得出的結論是,只有圈復雜度的分布圖才真正有用.

那么,什么可以用于表示更大單位/抽象級別(如文件/組件/子系統(tǒng))的可維護性級別？我發(fā)現(xiàn)第一個指標是代碼行中單位的大小.如果限制文件的大小(如1000行)并限制文件中每個函數的圈復雜度,則會有相對“簡單”的文件,因為它“很小”并且只包含“簡單”函數.您可以包含或排除注釋/空白行或僅計算語句或僅計算可執(zhí)行行…

但是,我的結論是,在這個特定的應用程序中并不重要.只是限制一些“大小”指標,它在大多數情況下都可以達到目的.稍后您可以考慮限制每個組件/子系統(tǒng)的代碼行總數.它將具有相同的效果 – 組件“簡單”,因為它包含“小”數量的“簡單”文件.

你提到的帖子非常好.它可以擴展到更廣泛的度量,通常被稱為“可維護性指數”.如果函數很復雜,文件很大并且頻繁更改,測試覆蓋率很小等等(在此處添加您認為定義的可維護性),索引非常高.我知道,這是找到重新分解熱點的最好方法……

免責聲明：我正在尋找執(zhí)行用例場景的Metrix++工具,我在上面解釋過.

總結

以上是生活随笔為你收集整理的java复杂性_如何衡量C或Java文件的复杂性？的全部內容，希望文章能夠幫你解決所遇到的問題。

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