What's is a good ratio of Class to Lines of Code for Object-Oriented languages?

Question

What's is a good ratio for the number Classes to Lines of Code for an Object-Oriented language (say C++,C#,Java and their likes)?

Many people, including managers, like the traditional LOC (lines of code) metric to measure the complexity of software, while many hard-boiled Object Oriented developers will say LOC is worthless its Class count that matters. And personally I believe that Classes may be a more reasonable metric of complexity, but that without a LOC metric the actual complexity of those classes (amount of poltergeists and gods in there) is hard to estimate.

Thus does anybody know of what is likely to be a healthy ratio for some fairly well coded software?

Edit: In this particular case, I'm looking for a ratio to determine a ball-park estimate of how much refactoring might be required to clean up the code.

Edit: Does anyone know of ratios for some big OSS projects like Firefox, Apache, Webkit, etc...?

Answer 1

There is not really going to be a good, definitive or satisfying answer for this question. However, I will say that in my experience, the lines of code per class decreases with increased experience in Object Oriented programming.

Most people who have not studied object oriented design principles will tend to have classes with lots and lots of lines of code. People with a lot of object oriented experience will tend to have fewer lines of code per class, but will have a lot more classes. And of course, both will complain about each other :-).

Answer 2

LOCs or NLOCs aren't really a good measure of quality or health of your code. I recommend using NDepend's static code analysis (for you .net peeps) to see how well your solution is architected.

I find that LOCs is good measurement only at the method level. That is, I generally like my methods to fit on a screen (no small fonts). Other metrics like Cyclomatic Complexity and Code Coverage (for you TDDers) in addition to your unit tests can give to a better feel for how healthy your codebase is.

Answer 3

If you're really just looking for a rule of thumb then I would say that any class that can't be printed out on a single sheet of paper at a readable resolution is possibly too long and should be refactored. Your target mark might then be on the order of 100-200 lines but, to my mind, the number of pages factor is a little easier to cope with.

I also firmly believe that the number of pages metric should be considered as a factorial measure of badness rather than linear. If there's a ten page class in the code base, that feels like it's at least three million times worse to me than a small well-architected class.