[GlenAnderson]

What would you use instead?

LoC isn't a perfect metric but it is very easy to relate to. Given some extra context like the type of application, the size of the company or the age of the codebase one can mentally account for some of the weaknesses of using LoC as a metric.

If this were a study using LoC as a sole metric with no other context I'd agree with you but LoC seems perfectly adequate in this case.

[Darmani]

Halstead complexity? Cyclomatic complexity? Those are just a couple of famous, old-school ones.

Software metrics is a major research area, and dates back to the 60s. The paper "Software Metrics: A Roadmap" has a good summary of the state-of-the-art as of 2000.

[Silhouette]

Could you, off the top of your head, give a rough idea of what cyclomatic complexity or Halstead complexity corresponds to a "large" project? In fact, given even a very simple code snippet, could you state on a cursory examination what these complexity values would be? Could most people reading this discussion?

If not, your alternatives don't serve the required purpose. Everyone gets that a project with 10 million lines of code is big. Whether it's bigger in any useful sense than another project of 8 million lines isn't really the point, and any alternative that doesn't have an immediate intuition for people reading the discussion isn't helping much.

[stonemetal]

http://www.neverworkintheory.org/?p=58

After controlling for lines of code, most complexity metrics become worthless.

[austenallred]

You're right; in this case it probably is adequate. I'm by no means an expert programmer (alas, I come from the business development/marketing side of things), and I used to measure things in LoC as if it were a be-all end-all metric. Then I started programming and realized how ridiculous that is.

It's probably the best metric to use, I just wish there were something better.