good code


Good code is a phrase that’s thrown around a lot. Whenever I speak to other developers at conferences, or my friends a phrase that comes up a lot is “good code”. e.g. “Yeah it’s not bad where I work, you get decent perks and the code is good”.

This got me thinking. What makes code good? Initially my thoughts were good code is subjective and the only way to know if the code is good is to trust the person that is telling you it’s good. This makes sense if you’ve worked with people before or know of their work and know they’re a good dev, then you trust in their ability to identify good code. But is there anything that makes code objectively good? Well maybe.

Let’s say it must meet some basic criteria.


What is my purpose robot

It must have purpose. This one is easy. We wouldn’t be writing it if it didn’t have some purpose. So as long as code has purpose we can tick this one off.


Rick and morty going really fast

It must run reasonably fast. Ok it’s started to get a little blurry. But let’s stick with it. Let’s say as long as the code we have written executes at the same speed or faster than a human could do the same task then it’s good.


It must be readable. Ok this is super vague and is where we need to dive a little deeper. Partly because this isn’t exactly measurable which is a shame because it’s arguably the most important.

I guess we can look at some very basic code and decide if it’s good or not. Specifically let’s focus on readability, no code golf today.

A very small example

The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.

This is good code, insanely basic but good. It’s super clear what we are doing here. Arguable improvements could see us adding parenthesis to make it absolutely clear.


The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.

This is now unnecessarily complicated considering it is essentially the same basic code as above. You could try and argue that some parts of this are reusable this way but all we are really doing here is rewriting default operators.

More importantly this relies on the developer to be responsible and keep functions scoped and name things perfectly. Even if they do I’d bet that most people would look at the functions internals just to make sure anyway.


Some code is subjectively good, some code is objectively good and occasionally it’s both.

We should try and keep things simple. Try not to wrap small chunks of code in functions just because someone in the distance shouted single responsibility. Units can be made up of other units and just because they do more than one thing it doesn’t mean they are no longer singularly responsible.

As always we should always try different things because programming isn’t a science or an art but a craft. A beautiful mix of them both.