Jump to content
  • Advertisement
Sign in to follow this  
Turold

Code Metrics

This topic is 3798 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need a tool which can be attached to VS2005 and can generate nice HTML report with various project/solution stats. All kinds of useful or just amusing things. What do you recommend?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!