Clean Code A Handbook of Agile Software Craftsmanship - Metrics

[Iván Párraga]

Hi,

One possible way to measure the quality of the software is to have as much as possible automated metrics using tools such as FindBugs, PMD, Checkstyle, Simian, Cobertura, etc. They provide fast feedback and give an overall perception of what the quality of the code is. In fact, in some organization these metrics are used to evaluate how good a project (or a developer) is.

Do you think this is a good approach? Do you think the use os these automated tools is enough to measure code quality? If not, what is your proposal to detect bad quality code taking into account some of the pressures of our industry such as time pressure?

Cheers,

Iv�n

[Ilja Preuss]

At the Agile 2008 conference, in his keynote Uncle Bob proposed that the only meaningful metric regarding code quality is "WTF per minute". I guess it was only partly tongue in cheek...

[Alaa Nassef]

Originally posted by Ilja Preuss:
At the Agile 2008 conference, in his keynote Uncle Bob proposed that the only meaningful metric regarding code quality is "WTF per minute"

Nice one, but I have a comment. Those metrics might prove useful in some areas regarding code quality (following a certain coding style, number of parameters in a method, LOC in a method, etc.), but they are not enough. The human factor is vital, and it's the most important

[Lutz Hankewitz]

How about the OOAD Metrics from Chidamber and Kemerer
OOAD Metrics from Chidamber and Kemerer


Unfortunately I saw these metrics just in expensive Metrics collecting tools
for C++ in the past.

Do you have any experince with these? Or do you avoid these kind a
metrics?

Kind regards,

Lutz

[Alaa Nassef]

There's a nice plugin for eclipse called metrics that does some of that which is great, but as I said earlier, those plugins help you a little bit, but I can write lousy code that's going to produce good results in metrics tools.

[Jeff Langr]

Originally posted by Alaa Nassef:
Nice one, but I have a comment. Those metrics might prove useful in some areas regarding code quality (following a certain coding style, number of parameters in a method, LOC in a method, etc.), but they are not enough. The human factor is vital, and it's the most important

Absolutely.

Low numbers on such metrics give us places to look for improvement. High metrics do not guarantee anything. In some cases, I've seen really good numbers backed by fairly bad code.

Jeff

[Robert Martin]

Originally posted by Iv�n P�rraga:
Hi,

One possible way to measure the quality of the software is to have as much as possible automated metrics using tools such as FindBugs, PMD, Checkstyle, Simian, Cobertura, etc. They provide fast feedback and give an overall perception of what the quality of the code is. In fact, in some organization these metrics are used to evaluate how good a project (or a developer) is.

Do you think this is a good approach? Do you think the use os these automated tools is enough to measure code quality? If not, what is your proposal to detect bad quality code taking into account some of the pressures of our industry such as time pressure?

Cheers,

Iv�n

I think there are some very good metrics to follow. Cyclomatic complexity should be kept to a minimum. Method size, and class size should be small. You can read my PPP book (http://tinyurl.com/5ebk7h) for some of the dependency metrics that I like to use.

...However, metrics are a carving knife when what you really need is a scalpel. Metrics can tell you something is wrong, but they can't give you much guidance about the precise cause. In the case of clean code, the cause is discipline and professionalism (or it's lack). Fixing that problem is a matter of instilling pride of workmanship into the team.