I agree. It's not an important metric from a technological standpoint, but it sure gives some sense of accomplishment.
I've done, for old VB6, a code statistics generator. Pretty simple, but it gave a good sense of how complex a project was. It calculated (among other things):
* Number of lines.
* Percentage empty lines.
* Percentage of comment lines (any line that had a comment, either full line or simply the end of the line).
* Average line length (blank lines excluded).
* Median line length (blank lines excluded). Useful for getting a sense of how "meaty" the lines are. Probably should have done a histograph on line length as well as I had collected the data anyway to calculate median), but didn't get around to it.
* Number of declared external DLL functions.
* Number of variables.
* Number of subs.
* Number of forms.
* Number of controls in forms.
* Number of classes.
* Number of selections (if, select...).
* Number of iterations (for, do...).
* Number of selections/iterations adjusted for complexity (first nesting level counted as 1, second for 2 et cetera).
* Number of recordsets.
This was actually all pretty easy, just reading all the source files line by line, look for some keywords and do some simple counting, but it was immensely useful for measuring complexity of projects. For example, it was very easy to see the difference between a calculations heavy data analysis system and a more typical database frontend. Sure, it isn't perfect, but used with some common sense, it's plenty good enough. We used it a lot at my last job, to make time estimates.
If I feel like it, it might get around to doing one for B4A some day...
)
