The easiest way to differentiate between a good developer and a bad developer is the state in which they choose to leave their code. There are always reasons to rush through coding a project, but a good developer always seems to find the time to make the effort.

There are a host of reasons to write clean code. We could talk about professional pride, about maintaining standards, but let’s take a moment and acknowledge the cost of bad code.

Is your dirty code showing?

Dirty code takes exponentially more time at every level of the development lifecycle. It takes longer to track down bugs, to build new functionality, or to even  estimate the cost of a feature request. Because of the added cost is touching a dirty project developer moral becomes an issue. For most developers working with someone else’s messy code is kind of like using a port-a-potty. Get in, get out as fast as you can and try not to breath.

If you haven’t had the pleasure of working with a dirty code base, picture it as a dirty room. Your objective is to find and fix one tiny bug, the equivalent of finding a matching sock. In a messy room, like my daughter’s for instance, this is a monumental chore (it’s also why she went to school with only one sock on this morning). The difference is between a messy room and a clean room is that, in a clean room there is only one place you need to look.

So what is clean code?

If you were to take 100 developers and ask them what clean code is, you would get 100 different answers, and usually a couple of arguments. So lets boil it down to the essentials.

Easily accessible code is straightforward, has good abstractions, and is clear in its intent. This means that any developer can pick up the code and work with it. Everything is where it should be logically and everything is laid out as most would expect.

Clean code is made for the real-world, so it has a clear error-handling strategy. It should cover all of the bases for the software scope and where needed, it prevents the user from experience errors. People say “Garbage in, Garbage out” but with clean code when the user enters garbage into the system we handle it in a way that doesn’t crash the system.

The cleanest code possible is minimal, any given routine does one thing, only uses the resources that are needed for that task and performs it’s task well.

I like my code to be elegant and efficient. The logic should be straightforward and make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Bjarne Stroustrup, inventor of C++