Doesn’t anyone here have any actual training in metrics? Those of us who have been doing this for a while - and were properly trained - know that LOC, as bad as it is, does work. What you’re all dancing around is the fact that, like any metric, IT MUST BE CALIBRATED to the environment.
BTW, a line of code is a line of code is a line of code, as long as you count consistently: I once had a project where we counted the lines three different ways to keep the lunatics upstairs happy, but, once each measurement was calibrated, they yielded identical results across products AND, strange as it seems to the uninitiated, even across languages. (The catch there is that the higher the level of the language being used, the less lines of code required to produce the same functionality - see the works of Halstead for a complete explanation.)
As far as using LOC and the limitations thereof, refer to Barry Boehm’s work (the CoCoMo guy).
If you’re a Function Points fan, just try to compare an embedded system’s size to that of a typical COBOL app using the FP counting rules - it can’t be done. BUT, it can when using LOC and full-blown CoCoMo.
Bottom line on counting: it doesn’t matter how you count, as long as you consistently count the same way. Count comments or don’t; count white space or don’t; count declaration statements or don’t; count multiple line statements as one statement or don’t. As long as you do it the same way, it can be calibrated and used effectively.
HOWEVER, the BEST way is to maintain appropriate detailed records of productivity and refer to them. Just remember, you’re asking for an ESTIMATE, not the final numbers. And ESTIMATES can vary as much as 16x at the beginning of a project.
Better to have a rock solid development process that runs the amateurs off and keep your software folks under control so they don’t introduce unneeded functionality or experiment more than necessary.
If you want a challenge: count non-blank characters instead. Then you can argue over whether or not long variable names cost more than short ones. They can easily be shown to cause more compile errors due to typoes, but does the maintainability increase offset it?
Folks, this is a tempest in a teapot: use what works for your organization. Don’t waste energy arguing over which end of a soft boiled egg is the right one to eat it from!