Can "good code" be measured?

I was recently reading Code Complete, a really good book on writing better software. Naturally, I had a lot of questions while reading it, but the biggest one that kept coming up was, "Can I measure this?" or "Can I quantify this?"

I'm aware of static code analysers, and the vast improvements they bring, but I don't think they can do most of what the book teaches.

So can we write software that "measures" the quality of our software?

Comments

[Spyros Argalias]

I'm not sure if the question is asking how a programmer can measure whether their code is good as they're writing it, or whether applying programming principles and writing good code makes any difference to projects. I'll try to answer both.

How to know if you're writing good code

Programming principles help you with things such as:

• making code easy to understand (and therefore making it correct, as misunderstandings about how your code works = bugs)
• making code easy to change (refactor and add features to)

That's it. So to know if your code is good, ask yourself questions like:

• is this code easy to understand? Would someone who's never worked on this code before understand it?
• is this code easy to change? If I want to change X to Y will I have to also modify 500 files in the system? If I want to change how this data is validated, will I have to change it in 500 places or have I kept my code DRY and can change it in only one place?

Most of the principles of clean code are just about keeping code simple, organised and independent.

You want small functions, that do one thing, because they're easy to understand. They're also easy to reuse, test and change. There is no unrelated code in the function that you could break accidentally during a change.

You want units of code to be independent and predictable. As a result, you don't want your units to be accessing things outside of their local scope, because things outside of the local scope can change for many reasons. That's not simple to track and remember. In comparison, a function that only accesses things in its local scope is 100% predictable and much simpler.

So basically, just think it over and consider whether the code is easy to understand and easy to change.

In terms of concrete measurements, you can only get what static code analysers give you. Things like:

• how many lines on average are your units of code and files? (More lines correlates with code that is harder to understand.)
• are functions accessing non-local variables?
• what's the cyclomatic complexity in your code (number of nested conditional statements)? (Obviously more means that code is harder to understand and change.)
• are there known vulnerabilities in the code?

Measuring whether good code makes a difference

Good code is code that results in good projects. It makes sense that applying programming principles that keep code simple and decoupled results in vastly better projects. However, to prove it, you would indeed have to measure it over multiple projects. You could do something like measure the success of different projects you've worked on along with characteristics of the code in those projects.

Some metrics you can measure about the project's quality / success:

• how many points do developers complete per sprint? Are developers completing less points now compared to when the project begun? Are they completing significantly more? (This point is very good proof on whether the code is bad or good. However, it requires Scrum / Kanban to be implemented properly, with consistent point estimation.)
• does the code frequently have bugs? Are those bugs usually caught in production?
• does the build break frequently?

Along with that, you can measure characteristics of the code as mentioned above. For example, things such as how easy the code is to understand and its cyclomatic complexity.