Why does clean code matter?
Surprisingly often I encounter this type of question in one form or the other.
What’s the point of clean code?
If the code has been written, and it does what it’s expected to (satisfying the business requirements), and doing this in a most efficient way (performance speaking)? So why we just can’t leave it alone?
To start with, I need to clarify what the “clean code” is.
The codebase is a reflection of reality. And so the clean code is the code that reads like business requirements. “Clean” not in the sense of being understandable by an average developer, but in the sense of being a close reflection of the business area.
That’s important because this definition is objective, vs. “understandability” which is subjective.
Strictly saying, in an ideal world, the complexity of code should be a linear function of business area complexity. Otherwise, a small change in business requirements would lead to a big change in the codebase.
And it’s going to get worse for every next change, leading to even bigger changes in the code.
Until one day the codebase becomes unmanageable.
Let’s see a pseudocode example (which also happens to be a perfectly valid ruby)
if credit_card_expired(user) disable(user) end
This piece looks good. It explicitly communicates the requirements to us, namely, “if the credit card expired the user should be disabled.” That’s nice.
Now let’s look into the
def credit_card_expired(user) return user.credit_card.valid_till < Time.now or user.compromised? end
It turns out the name of the method doesn’t describe what it’s really doing. What’s more, there’s a business requirement right there, but it’s hidden, implicit. It’s saying “If a user is compromised, disable him.”
How to make it explicit? Obviously, we need to put it on a higher level of abstraction.
if credit_card_expired(user) or user.compromised? disable(user) end
Always ask yourself, does my code communicate the business requirements in a most explicit way possible?
If not — refactor, and ask again.
Clean code matters.