Quantifying good code
“Good code” is a very undefined term and a very difficult one to explain or quantify. On top of that, good code depends on the underlying language, on the type of application – or even the processor architecture. All of these characteristics define “good code” more as following best practices rather than a fixed rulebook of sorts.
So, instead of trying to come up with the do’s, let’s talk about the dont’s.
Don’t make your code unreadable
Even though this one is self-explanatory, take it from us – you wouldn’t work alone on a serious project.So in order to collaborate effectively you need to make sure that your code is readable. Below we’ve tried to provide a few tips that you might find useful:
a. Format your code
If your code even remotely resembles the extracts above, you should probably do one of the following:
- Quit programming
- Follow code guidelines & start by extracting methods
Formatted code is not a question of aesthetics, but a very pragmatic question of productivity. Not even yourself would understand your code an year from now. And how do you hope to start debugging? How would you know which parenthesis closes which code block?
b. Reduce code complexity
Most interpreted languages limit classes to 100 lines of code. It’s a good rule that promotes code simplicity. But 100 lines may look much like this:
And that’s only 50 lines. Here, a Python 1-liner:
Surely, a rule set can’t be specific enough to limit you from inserting complexity – even naming variables could potentially introduce unnecessary complications (more on that later). But you could still try and make simple calls that one could follow through logically, and evaluate at a later stage. In our minds, good code is exactly that – a sustainable blob, that you can bend to your will once you need to – without revisiting the entire code base.
c. Reduce redundant code
More often than you would believe, we’ve seen swarms of unnecessary functions like these:
Wow! Have you forgotten how to multiply? Or you can’t evaluate a function on the fly, so you need to make a separate call? This is not better OO, just redundant code, that one spends time writing, another person reviews, and, should they both agree, get released to production to waste storage and process cycles for eternity.
Naming conventions
Sometimes, not naming variables with random strings simply does not suffice to produce readable, and more importantly, understandable code. Explicit languages, like Ruby, depend on naming way too much to be readable also by non-pros – so much, that BDD tests could, hypothetically, be written by product owners and not developers.
Let’s, however, focus on the easy, obvious wins first:
Well, that’s handy. And not confusing at all.
Sum of Sums is difficult to express, but still the spoken language has come up with terms as “subtotal”, “total” and “grand total” to help that specific case. And if millennia of language evolution can produce a word like that, so can you!
We’ll be covering more “good code” best practices later this year – before that, make sure to cover all “easy wins” and start reading a style guide 🙂
