You seem to be confused about the purpose of metrics. They are NOT an end in themselves, and they are NOT useful in isolation from the code. In demanding such things, and exaggerating the abuses therein, you are setting up straw men and knocking them down in puffs of rhetoric.

I am anything but confused. On this subject, I am very clear. But okay. I'll play. You explain it to me.

Exactly what use are you going to make of the numbers in your table above?

But be warned! I've been here before. The moment you explain a use of those numbers in your table, you will be making judgements based upon them. And the moment you do that, you are using the numbers to in some way represent the code they are derived from.

If those numbers can only be used in conjunction with the code itself, then what part do the numbers play? What purpose do they serve.

If you answer that question honestly, you'll see that nothing in my post was rhetoric. It is all based upon having been there, and done that, and seen the effects that it has.

By themselves, nothing. But I am (and was) arguing that they are useful as clues that can lead to profitable conclusions.

I would also (and have, recently) argue against the idea that they should serve as commentary on code quality, or heaven forbid, "quality gates" for code review.

So, if they can't be used in isolation, why have them?

I routinely deal with large amounts of source code, and most of it is the product of many many unique minds over many years, combined with an endless treadmill of maintenance and tweaking. Apart from asking the individuals with the knowledge - who have often left the company by this stage - what else can I use to help focus my (our) attention for code review, unit testing, and so on.

Obviously, I can also find clues in reported problems, but isn't that just another metric?

If you find them useful, then nothing I (or anyone) could say would nor should stop you from using them.

Personally, I don't feel that they were worth the effort of deriving, and worse, they can (and are) misused and so become dangerous. I have tried to explain my reasons why I feel this way.

Obviously, I can also find clues in reported problems, but isn't that just another metric?

Yes it is, but it is repeatable and comparable. If you have two projects/sites/customers or if the program is widely used, even two countries, then both the expectation and practice is that assuming other factors (number of users, programs runs, volumes of data etc.) are roughly equal, then you will get a similar number of error reports from both groups of users. And after maintanence, you should be able to measure the the drop in error reports.

Whilst LOCs may give you an indicating of how big the code is, it gives you no indication of anything beyond that. The code could be easy to maintain, or never need maintainance. Equally, a short module could be a nightmare. Most of the other numbers are similar. They measure something, but deriving meaning from them is almost impossible.

Code complexity is different and worse. It attempts to heuristically derive meaningful numbers for a specific purpose. That of allowing some judgement to be made about the quality or complexity of a module without inspecting the code. And that is where the numbers become not just almost meaningless, but dangerous as well.

Giving an absolute number for "compexity" is meaningless. "It's complexity is 50!". 50 what? Is 100 twice 50? Is there some cutoff point, 100 or 500 at which code is "too complex"? Obviously these questions are rhetorical. Complexity is relative, and the numbers can only be used comparatively.

The problem is that the number does say anything about (or make any consideration of) the complexity of the problem being solved. As I said somewhere above, you cannot reduce the complexity of the problem by measuring the complexity of the solution. Beyond more bad anologies, the only way I can substantiate this claim is by example.

Two pieces of code that set out to, and achieve, solving the same problem. They are written in the same language by two reasonably competent programmers.