Like most developers, I don't really care for software metrics. Writing good software is more like an art (or black magic, if you will) than an exact science. It takes years of learning and experience just to recognize good code, let alone writing it. A mathematical formula simply won't cut it for measuring code quality.
But still, I've always hoped that there'd be a simple method to determine how good an object oriented system is. The closest I've gotten was from a book (by Martin Fowler I think) that says something along the line, if you look at a good OO system, all the classes and methods are pretty small and simple and "don't seem to be doing anything"; it's through the interaction of these objects that complex behaviours emerge.
In our organization we have a separate "tools team" that does the builds for us. They use
CruiseControl, bundled with everything under the sun: run unit tests and functional tests, provide test coverage reports through
Clover, check coding standard using
CheckStyle, run
JDepend to analyze packages and cycles. But probably the most interesting is the class level design quality metrics produced by
Essential Metrics. Of those the one that comes up most in our conversations is Cyclomatic Complexity.
Googling it will lead you to
Software Engineering Institute's site that spits out a formula
Cyclomatic complexity (CC) = E - N + p
In reality it's a pretty simple concept. Cyclomatic complexity measures the number of decison points (
if
,
else
,
for
,
while
,
switch
etc) in each of your methods. The higher the number, the more complex your methods are, and in theory the more difficult it is to understand and maintain your system. The
example I gave previously has a cyclomatic complexity of 7, which ranks at the top in our current small project.
But how is that related to how objected-oriented your code is? Well, over the years I've discovered that for a poorly designed OO system (if you can call it OO), it's almost impossible to avoid large amount of
if
's and
else
's, or worse,
switch
's. On the other hand, a well designed OO system (few and far between) has very light use of decision logic, usually only for checking boundary conditions (e.g.
if
argument is
null
). In other words, if your method is not "doing much", it probably has a low cyclomatic complexity.
low cyclomatic complexity == good OO code
As for the root cause of this, if you've come this far, you can probably figure it out yourself, right? :)