Developers
Get Involved
By

The best code ever

Why you should be really thinking before you type

The best code ever is the one you don't write.

I’ve spent years writing gazillions of lines of code, but lately, whichever codebase I’m working on, it looks like I have a taste for deleting lines rather than writing them, and I feel like I’m improving as a developer.

Can you see it? A white line without code: no bugs, no maintenance, no issues. Just a line in which your mind (and the computer) can dwell and rest.

Now that I’m in the realm of “Teaching kids how to code”, I think it’s time to start writing about this feeling, and my thoughts on code, libraries, etc. Hopefully this will be the first of a series of posts on this subject.

Let me elaborate on the concept of “not writing code”.

What is good code ?

More than “It should work” (which I take for granted) there are various ways code goodness is defined, I’ll just try to summarise the ones that I consider important.

Good code is:

  • Testable – You can easily write a test to cover its functionality.
  • Readable – Other people can follow it, possibly even if they don’t know your language.
  • Performant – It’s fast.
  • Maintainable – It’s easy for others to change it or move it around without breaking it.

The more lines of code you add to a codebase, the more complex it becomes.

More lines mean more cases to test, they mean that the code is harder to read, less maintainable and potentially less performant (the latter isn’t generally true, but in practice code seems to go towards degradation rather than improvement).

Writing less code, cleaning up what’s been left behind and deleting files maintaining the same functionalities just makes codebases better. Pushing yourself towards writing less code forces you to be more organised and just improves your effectiveness in solving problems.

How do you build software then?

I’m not saying you shouldn’t write code, I’m saying you shouldn’t write any unnecessary code. You can just apply a few rules to write better code:

  • Understand your requirements
    • Do you understand fully what your piece of software should do?
    • Did your “customers” really want that super-complex requirement they asked for? Do you maybe need to clarify that and explain the implications?
    • Can you break the requirement down?
    • Can you remove any gray area?
  • Think before you type
    • Plan ahead the layout and the structure of your code
    • Divide between data and behaviour (more on this in future articles)
    • How can I apply good coding techniques? Should I ?
    • Ask yourself: Do I really need that?
  • Know your codebase
    • Check if the codebase you’re working on has parts that already do what you need
    • Check if there are parts that can be improved with your new code and allow you to delete more code
  • Know your language
    • Sometimes in the language you use, someone has already solved some of the problems you’ll be facing
  • DRY Principle
  • Wu Wei – The relation with this might be a bit harder to grasp… and that’s the idea.

Some Cheeky Examples

Look at the code below:

function doSomething() {
    return true;
}

Is it testable? Is it readable ? Is it performant? Is it maintainable? Now, look at this:

function doSomething(a, b) {
    var c, d;
    for (c = a * b * 5; c > 0; c--) {
        d = !!(a * b * c);
    }
    return d;
}

Is it testable? Is it readable? Is it performant? Is it maintainable? What does it even do?

What about the next piece of code?

//

A line with no code, beats the first example in performance :).

Written by
Senior Web Engineer at Kano