Software Metrics

I'm not sure, does that include Lines of Code and LCSAJs?

The only metric I've ever run across with some actual meaningful use is cyclomatic complexity.


That's not to say there aren't more out there, of course.

I'm quite a fan of "number of tests per module" and "number of tasks completed per day versus number of tasks added per day"

I use the eclipse metrics plugin, which provides a handy list of various metrics at the bottom of the webpage.

Personally I only find the cyclomatic complexity useful though.

I find code coverage to be the most useful; the measure of percentage of executable statements that are executed out of the total number.

Edit: P.S. Code Coverage is used to determine if your Unit Tests testing every available logical branch. It give you an idea of how effective your tests are in checking all conditions that will be handled by your program.

This is old, but interesting nonetheless:

Object Oriented Design Quality Metrics: an analysis of dependencies

And the author has a related shell script here:

Quote:

depend.sh - Dependency Analysis Script This is a bash script that calculates the dependencies described in the paper "Object Oriented Design Quality Metrics: an analysis of dependencies". It walks through a directory structure of C++ programs and generates reports that show the values of the metrics for each class category.

Quality oriented metrics:
* Bugs per line of code
* Warnings per lines of code
* Bug pareto chart (if you add criticity to your bugs, you can build a comparison chart that will tell you what is the current state of your software; it's kind of helpful with big code base, and it forces you to work on the most critical bugs first - which are supposed to be the more difficult to cope with). I am quite used to a simple pareto function which looks like P = sum(n=1, n<=p, (C(n) * Kn)). C(n) is the number of bug that have a criticity of "n", and Kn is the weight of a criticity "n" bug. Now let's imagine that we have 3 C levels (A = hyper serious, B = important, C = really, we don't care much). We affect them a weight by defining how many bug of which kind are acceptable at the time of shipping. For example, we can accept 0 A bugs, 3 B bugs or 10 C bugs. We set Kc to 3, Kb to 10, Ka to >30 and we say that our pareto must not exceed 30.
You can then track the evolution of your pareto function result over time - at fixed intervals.