Intro

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.

Purpose

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.

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.

Readable

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.

const x = 4 + 5
x === 9
true

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.

Ok what about the same code refactored.

const add (a, b) => a + b
const isNine = x => x === 9
const doit = () => isNine(add(4,5))
doit()
true

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.

Conclusion

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.