Comments on: Which Code Metrics Do You Consider Important?

By: Weekly Links #83 | GrantPalin.com

Weekly Links #83 | GrantPalin.com — Sun, 13 Dec 2009 22:58:00 +0000

[...] Which Code Metrics Do You Consider Important? Good information to collect for any programming project. [...]

By: Davy Brion

Davy Brion — Fri, 11 Dec 2009 15:31:18 +0000

http://davybrion.com/blog/2009/12/ndepend-and-lack-of-cohesion-of-methods-not-to-be-trusted/

that’s an example of how incorrect the LOCM and LOCM HS methods can be

By: Reflective Perspective - Chris Alcock » The Morning Brew #495

Reflective Perspective - Chris Alcock » The Morning Brew #495 — Thu, 10 Dec 2009 09:55:04 +0000

[...] Which Code Metrics Do You Consider Important? – Davy Brion discusses the topic of Code Metrics with a look at the various metrics offered by NDepend, classifying them into ones he finds useful, and ones that you might thing would be interesting but he doesn’t find interesting. Some good discussions starting in the comments on this one [...]

By: Łukasz Podolak

Łukasz Podolak — Thu, 10 Dec 2009 08:57:59 +0000

one more, often forgotten: the size of your wallet

By: Davy Brion

Davy Brion — Thu, 10 Dec 2009 08:47:08 +0000

@Patrick

no, i’m saying that:
a) some of the metrics show bad results, even though the code is good and i think it’s solely because of DI/IOC
b) some of the metrics are wrong (i think)… the number of fields reported for a type is often incorrect when lambda’s are used (even though the anonymous classes also show up in the report) which ruins the LOCM metric

By: Patrick Smacchia

Patrick Smacchia — Thu, 10 Dec 2009 08:43:55 +0000

Concerning coverage;
High Test Coverage Ratio is a good thing, Anyway!

Concerning DI/IOC, basically you say that because you abide by good abstraction principles, metrics values will be good anyway and you don’t need them. The other half is true, if metrics value are bad, it certainly means you don’t abide by good principles and thus, metrics are useful )

Btw, instability IS a better thing than stability (in the context of abstracness vs. instanbility), since instability means that changes won’t propagate too much.

By: Davy Brion

Davy Brion — Thu, 10 Dec 2009 05:54:41 +0000

@Patrick

that would only be useful of if the code coverage metric was actually useful

any thoughts/comments on what i said about the metrics that i think are irrelevant when using DI/IOC?

By: Patrick Smacchia

Patrick Smacchia — Wed, 09 Dec 2009 22:44:02 +0000

I found metrics on method level pretty useful:

NbLinesOfCode, NbILInstructions, Method rank, Afferent coupling at method level (MethodCa), Efferent coupling at method level (MethodCe), Code Source Cyclomatic Complexity, IL Cyclomatic Complexity (ILCC), IL Nesting Depth, NbParameters, NbVariables, NbOverloads, PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered, PercentageBranchCoverage

but my preferred measure, is to assess how changed an new code is covered by tests:
Are you sure added and refactored code is covered by tests?

By: Matt Lacey

Matt Lacey — Wed, 09 Dec 2009 17:15:44 +0000

A few things I like to keep track of:
- Undocumented public methods
- Code coverage of Unit tests (but being aware that this isn’t an end to anything in itself)
- Number of comments (only zero is a flag – on a purely numbers level this shouldn’t need to be high if good naming used)

By: Davy Brion

Davy Brion — Wed, 09 Dec 2009 13:54:27 +0000

well yeah, but that’s not one that you can easily get out of any tool

By: Steve Degosserie

Steve Degosserie — Wed, 09 Dec 2009 11:46:24 +0000

The pain level it takes to add new features / modify existing ones is a pretty good metric, although a highly subjective one.