2009-06-09 127 views
13

我只是很好奇人們正在使用哪種代碼度量標準,以及關於如何最有效地使用代碼度量標準的意見/經驗。我們所有的代碼,無論語言,使用以下:代碼度量

  • 圈代碼的複雜代碼的
  • 耦合(具有面向對象的語言相比,程序和模板語言,不同的含義)

複雜性測量對於我們識別潛在的維修噩夢是最有效的。在較小的程度上,LOC作爲一種相對衡量標準也是有幫助的(如果我們看到一個班級進入的話,比平均班級多20行)。耦合的用處不大,通常最有幫助時,我們可以看看我們可能有多少事情隨着變化而斷裂。

我很想知道別人正在使用(如果有的話)代碼度量標準和上述指標的意見。

回答

2

我目前的公司並沒有真正保留任何代碼指標,這不是我的選擇。

我以前的僱主對代碼複雜性和代碼行進行了度量。他們對類文件的長度也有限制。太大的課程必須通過代碼審查,以便可以將它們分成更小的更合適的課程。這有時會讓人感到痛苦,但它保留了一個非常大的來源(100-200名開發人員在項目中)的維護性。

0
  • 林特
  • 圈複雜
  • 不幸的是,沒有別的
2

我們目前做的測試覆蓋率與EMMA作爲Maven插件。這很漂亮。它會告訴你到底有多少代碼是由你的測試執行的。我們使用JUnit進行測試。

0

我經常使用Dave Wheeler的sloccount,它給了LoC並且也嘗試了CCCC,儘管它現在有點過時了。

0

在貝爾,我們計算每個項目功能點(請參閱IFPUG)。

好:他們已經建立了一個相當大的項目成本數據庫。

缺點:它不是隻要新事物引入工作 - 而且由於計算機科學是不斷髮展的非常快,出現了幾乎每一次新的東西......

結論:指標都在不斷的還不錯環境。但是如果你改變了一些參數,他們有點沒用

Sylvain。

0

我一直在試驗Metrics plugin for Eclipse from StateOfFlow,我越來越喜歡分析我的代碼質量的想法。當然,並非所有的指標都對我來說太清楚或者有用,但是從插件提供的各種指標(目前爲14,按我的計數)來看,我傾向於認真對待這些指標:

方法度量標準:圓環複雜性|語句數|範圍內的當地人數|關卡數量

類別度量標準:字段數|每

類的加權方法,以進一步減少這個名單,我真的相信McCabe的圈複雜度措施,我覺得數量也被在一個地方做太多的工作非常有用的指示語句的。

在插件提供的其餘度量標準中,我發現中的方法組中的內聚缺乏而難以理解。今天,我開始了自己的一個小實驗,經過幾個小時的編程,我開啓了項目的度量支持。發現的6/7問題與凝聚力有關,一個特別令人驚訝:方法中缺乏凝聚力(總相關性)爲209%

我很難對這些做任何事情:Chidamber and Kemerer |亨德森 - 塞勒斯|總相關|成對的場相關。我很想提高這些指標的最大允許值,所以他們會停止顯示爲警告。

我認爲通過實時計算代碼度量可以爲編寫更好的代碼提供有用的指導。我很高興您提出這個問題,因爲我想了解更多關於其他人如何使用指標來提高代碼質量的信息。

順便說一句,我會歡迎您可能有經驗的其他(Eclipse)插件的任何建議。 StateOfFlow提供了一種很好的方式,可以用HTML和圖表格形式導出指標信息,還可以將指標導出到CSV文件,然後將其導入到您可能使用的其他任何實用程序中。我很喜歡這個插件:)

+0

這是一個很好的總結: http://www.ibm.com/developerworks/java/library/j-ap01117/index。html#N10228 他使用metrics.sourceforge.org(而不是eclipse-metrics.sourceforge.org)。這兩個插件似乎互補,但不是相同的AFAIK。 – user77115 2010-06-01 15:06:04

11

你會得到你所測量的。

因此請仔細選擇您的指標。衡量錯誤的東西會給你錯誤的東西。並不是所有的目標都可以直接衡量,所以你必須找到一個有希望與目標相關的代理。


關於我完成的最新項目,我測量了以下內容。這些都不完全是代碼指標,而是更高級別的項目指標。我認爲它仍然與這個問題有關。

  • 每日構建失敗率(與故障的根本原因分析),目標< 20%
  • 測試運行/合格率(自動和手動測試),目標每個項目相位變化;最終運行率目標爲100%,合格率爲95%
  • 新代碼的測試功能和決策覆蓋率(非UI,非遺留,未移植),API函數爲100%,其他函數爲80%,50 %決定
  • 打開錯誤按優先級計數,目標看到平坦或下降的曲線(團隊bug修復能力足夠),沒有高優先級錯誤
  • 檢查:組件大小,檢查工作量,嚴重性發現的問題;目標以獲得一種缺陷/努力/ loc啓發式措施,以確保組件足夠徹底檢查
  • 靜態分析工具,如lint和某些特定於域的工具運行,修復或理解高優先級問題
  • 團隊速度估計與實際每次衝刺相比,目標將估計誤差降低到20%以下

這些度量來自我們作爲項目的更高級別目標。簡而言之,儘可能早地運送足夠好的產品而不會招致太多的技術債務。

作爲檢查的一部分,非正式地檢查了大部分「代碼度量」問題。我們確實對系統有很好的感覺,所以我們知道最需要關注的最複雜的部件在哪裏。作爲程序員,我們也能夠檢測複雜性,而不訴諸正式的措施。

0

Essential Cyclometric Complexity是一個有趣的,它也給出了代碼是如何「非結構化」的指示。

非結構化代碼是使用中斷和gotos例如退出控制結構,如for循環。

不過,我知道的,唯一的產品可以使這個指標是McCabe IQ

+0

您的*基本Cyclometric複雜性*鏈接到** 403 Forbidden ** – Wolf 2014-12-16 12:53:18

2

我發現Type Rank和方法秩代碼度量是非常有用的,當你需要快速瀏覽你的代碼中的鍵類型/方法。類型和方法等級受着名的Google Page rank algorithm啓發。

如果你是在.NET環境中,NDepend會爲你計算類型等級和排名的方法(以及其他80個代碼度量)

+0

Interes + 1ng,您知道使用NDepend之外的工具可以獲得的* Type Rank *和* Method Rank *度量嗎? – Wolf 2014-12-16 12:56:30

1

有相當一些科學文獻上這一點。一項調查可能在Nachiappan Naggapan's thesis(對不起,我無法找到更好的論文訪問)。關於軟件度量標準的另一個演示文稿是here

在我最近使用C++代碼運行CCCC後,我開始瞭解一些衡量指標,比如Henry和Kafura的信息流指標。 CCCC是開放源代碼並輸出由2-3個不同度量組成的綜合輸出(sample)。