We've all seen bad code. We probably all have written some ourselves. Bad code is easy to spot. It's over complicated, hard to read, has too many dependencies, no tests and it breaks every time we touch it.
But what about good code? What does good look like? It's not so easy to define. Actually, entire books have been written about the subject. But there are some traits we can look for. I'll summarize some of the key aspects I look for when writing or reviewing code.
Good code is easy to read. It has short functions with a single responsibility, variable names are clear and concise (not necessarily short, clear beats short) and it's well indented. It feels like you can skim through it and understand what is going on.
Readability is my number one concern when writing code because we spend a lot more time reading than writing code. We don't just read code when we're reviewing it or when on-boarding to a new code base. We read code when we're writing code, refactoring, debugging or testing.
Number two is extensibility. Good code makes it obvious for the next person to know where to plug new functionality. It doesn't mean we should try and predict what comes next or overly abstract our code. It means we have clear boundaries and encapsulation in place and apply the right design patterns where needed.
Extensibility is particularly important in the current world of agile methodologies. Software requirements change and evolve over time and that is how it should be. We don't need to know all the requirements in order to produce good code. We just need to assume that the requirements will continue to change.
It does what it's supposed to do. This may sound too obvious but it's not always the case. Because what a piece of code is supposed to do is knowledge that very easily gets lost over time. That's why we can't assume any code is correct unless there's a test suite that proves it.
Good code is covered with tests and that's how we know that it works and continues to work over time as we build new functionality.