Code Metrics

AMD Code Analyst ?

... assuming you're looking for a code profiler.

I'm looking for something hardware independant. It should take a c++ codebase and generate a report: file count, line count, func count, global variables, class count etc, some complexity metrics etc.

Quote:

Original post by Turold I'm looking for something hardware independant.

CodeAnalyst is hardware independent. You do not need an AMD processor for it to work.

Quote:

Original post by Turold It should take a c++ codebase and generate a report: file count, line count, func count, global variables, class count etc, some complexity metrics etc.

This might interest you.

Code Metrics is terrible. This is a management created utility that attempts to "quantify" the work of a developer. There are tons of variables that will determine if you write 50 functions in 2 hours or spend 8 hours writing one complex function.

If your developers get a hint that you're basing performance on some arbitrary metric, you can bet they will find a way to boost that metric and 9 times out of 10 it is at the cost of performance.

Sure, nothing like saying, "My physics engine has 20k lines of code within 500 functions in 122 classes." But does that make it a good physics engine?

Happy coding.

I don't think code metrics are that terrible... You just need to interpret them carefully.
For example if you measure the amount of comments you wrote, ideally 30% of the source should be comments I believe.
So if you find that only 5% of the source is comments than that is definitely an indication that programmers aren't commenting enough. Then you investigate and if the complexity is low then you won't make an issue out of it. But if it isn't low then it's time to get the whip if you know what I mean. :P

If you were developing for .NET I'd recommend NDepend. Anyone who's interested in NDepend is invited to read my NDepend review. I give some advantages of having code metrics there, too.

BTW.: the number of lines in a project is certainly one of the less useful metrics. But counting the number of methods with more than e.g. 40 LOC is useful to spot places for potential refactoring.

Regards,
Andre

Quote:

Original post by LordShade Code Metrics is terrible. This is a management created utility that attempts to "quantify" the work of a developer. There are tons of variables that will determine if you write 50 functions in 2 hours or spend 8 hours writing one complex function. If your developers get a hint that you're basing performance on some arbitrary metric, you can bet they will find a way to boost that metric and 9 times out of 10 it is at the cost of performance. Sure, nothing like saying, "My physics engine has 20k lines of code within 500 functions in 122 classes." But does that make it a good physics engine? Happy coding.

Me thinks that code metrics are helpfull to the developper. They are not "terrible" nor they are "a management created utility that attempts to "quantify" the work of a developer". They are just another tool that helps you in your daily work.

Now, you have to read them carefully. Things like SLOC doesn't really help, but what about cyclomatic complexity? The number of functions per class? The number of lines per functions? The code/comment ratio?

This (French, sorry) article by a friend of mine (Christophe Moustier, method manager) shows how to use software metrics in order to control (as in "check often to see what happen") a code base. He uses SourceMonitor to get some advanced metrics about his code, Perforce to store his code revisions and Excel to build a 3D view of the metrics of the subsequent code revisions. The result is quite interesting, and his approach enabled him to speak about code stability using the vocabulary of landscape description (which is a good thing, as such a vocabulary is rich and easily understood by nearly everyone on Earth). For examples, a "rivers" shows that a particular metric didn't evolved as fast as the surrounding metrics. Refactoring introduces "canyons" and "cliffs" in the graphics, and code stability ultimately lead to a "plateau". This is -- IMHO -- an interesting use of code metrics.

The goal of code metrics is not to measure productivity. Anyway, measuring the productivity of programmers fails, whatever metric you want to use. But the tool is still valuable as a help to the programmer.