In search of code quality

I’ve been thinking recently about what ‘code quality’ and what the phrase means. How does someone identify the difference between low quality code and high quality code (or medium quality code)?

In my quest for knowledge, I discovered a few interesting things.

I discovered the Spinellis book, Code Quality: The Open Source Perspective. I haven’t read this yet, but I ordered it, and looks like it will be interesting.

I found an article on coupling metrics on the IBM site. The reading here was good, as I discovered they have a series of articles on code quality.

I found a few references to analysis tools for JavaScript (some lint-like stuff)

Over in the high brow world of the linkedin groups, I saw a bunch of people referencing code coverage as an indicator of code quality.

Nothing earth shattering, but some good information, and enough to get me thinking about what *I* think code quality is – and what it is not. I think it may be impossible to define code quality in a way that everyone will agree with – but that doesn’t mean I shouldn’t try.

We have some metrics that can give us an idea about code quality. Quality code doesn’t have any compiler warnings (ideally at the highest warning level), and it’s clean from static analysis errors and warnings. Complexity metrics such as cyclomatic complexity (basically, the number of paths through a function), or dependency metrics such as fan-in and fan-out can also be indicators of code quality.

But – let’s make it clear that while I’m a (big) fan of those indicators, that’s all they are. Running clean with static analysis tools does nothing to ensure code quality – or product quality either (I ranted a bit about this a few months back). In fact, I guarantee you that I could write (or show you) a piece of software that compiles with the highest warning levels set and passes any static analysis tool with flying colors…that still sucks. 

One thing definitely unrelated to code quality is code coverage. All code coverage tells you is what percentage of your code you haven’t tested at all. If you squint and have a few drinks, you can pretend a little that high coverage rates from unit tests prove code quality…but once you sober up you’ll realize that all you have are unit tests that exercise some amount of your code.

But we can go beyond code analysis tools. Testability (can I observe and control program flow), and Maintainability (“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” ref) are critical to code quality. Given a good reviewer, Thom Holwerda’s comic is also spot on – the only valid measurement of code quality is WTF’s per minute.

As I think about this, I find my mind wandering back to Pirsig. Quality and care are two different ways of looking at the same thing. Quality comes from care, so perhaps what I want to measure is the care put into coding. The fact that a developer wanted to compile at a higher warning level or turn on more static analysis checks, or that they cared enough to get the testers input on testability, or a peer’s advice on maintainability may be the best ways to measure code quality of all.

So now, perhaps, I’m in search of a way to discover and measure care.