Program metrics and programmer productivity

The thread on programmer productivity has been an interesting one, and the
objection to lines of code as a metric is a very valid one.  The obvious
flaw is that I'll simply generate many thousands of stupid lines of code
merely to influence the metric.  The counter to that is: my boss/peer group
won't like my code and will object.  Loudly.

Anyway, trying for a positive note for once, what if we turn the question
around a bit?  If we're really asking "Am I a good programmer?" then the
answer depends on my programs, doesn't it?  After all, bad programmers
aren't really productive, no matter how much code I, er... I mean they churn
out.

If we know a good programmer by her good programs, then how do we determine
what's a good program?  Code Complete has some words on the topic, but my
copy is at home so I can't quote verbatim.  Some thoughts:
Number of variables per function (more=worse)
Variable lifetime (longer=worse)
Variable reference distance i.e. set X on line 1 and not refer to it until
line 1000 (longer=worse)
Number of parameters per function (more=worse)

Scanning code to evaluate this is not trivial (Oh, for access to some
compiler work areas!) but they ARE hard numbers and they CAN be compiled
automatically and if the programmer writes code to influence the metrics,
her code WILL be "better."  At least, I think it will... What do you think?

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---