This article isn't necessary. So why bother? Well...it is and it isn't. What I mean by that is that any developer who's been at it for more than a year or so will already know what clean code is. So I'm preaching to the choir. I'm doing so anyway because many developers might need a gentle kick up the backside as a reminder. The topic is too big for a single article; for the time being I'll discuss how some parts of the community view this topic and why it's important to consider.

Defining clean code...

If you're reading this, you may have some experience with software development. So what do you think high-quality, clean code is? There are a few different ways to see it but all boil down to the same end result.

• Code should be self-documenting. This is not about leaving comments all over the place. This means function and variable names should be intuitive. Files and directories are structured so it is obvious how everything ties together.

• Code should be consistent. I'm not going to weigh in on tabs vs spaces or similar, but mixing and matching is the essence of a code pedant's nightmares. Consistent code means we can be more confident about what is intended. This in turn makes functionality easier to infer and mistakes easier to spot.

• Code should be pleasing to read. it should make you smile (from Uncle Bob's Clean Code handbook). This may be one of the more tongue-in-cheek ways of putting it. Still, perhaps you get the same feeling from looking at clean code as you do when looking at your kitchen after a good scrubbing. Or at least it doesn't make you grimace as if the dog's strolling through the same kitchen after a roll in the mud.

• The boy scout rule - boy scouts have a rule that campgrounds should always be left cleaner than they found it. If you're changing an established system, you should not feel obliged to refactor the whole thing. But if you leave every part that you touch a little neater than you found it, the quality will only improve over time.

For the topic as a whole, Becca Bailey summed up the point very well in an episode of the React Podcast (this is pertinent to front end devs but applicable to all code too):

• The site we're building is a user interface. But we should also strive to also see the code itself as a user interface where the end users are other developers. If a junior developer can't quickly figure out what's going on in the code, it's not clear enough (episode).

By this we don't mean avoiding using nifty shorthands or the latest technical paradigms that others don't know yet. It again means code should be easy to understand.

So I'm going to conclude my section on 'defining clean code' with a complete cop-out. The above might be some of the symptoms of 'clean code', but I'm not going to offer a definition of my own. You already know what it is.

Yes. The code angel exists within you too.

Even if you're certain you're the only one who will ever work on a codebase, it's still a good habit to get into. Think about returning to your own code in a year where 'clean code' can apply in two ways. First, we want to be able to understand the code after a break without taking a week to get into the right headspace. Second, any changes we make should also be 'clean' without involving lazy hacks to make a changes.

In some cases, when we're making clean changes to clean code, we can even know it works without testing it. This means the functionality was intuitive enough that we had a sense of how our changes would affect it. It goes without saying that we shouldn't only rely on this instinct, but it's a good start. For a more complicated change, we still know when the change we're administering is a good one. You have a clear idea of where you stand and where you want to go, even if getting there can be a bit finicky. The changes will (in theory) have fewer unintended side effects and will leave you better off when you come back to it later.

Other times, we make changes to code but we have a little voice in the back of our minds: there's a better way to do this. I know my approach to this problem is anti-pattern, but doing it 'correctly' will take much longer. Or, maybe it's overkill for this purpose. Besides, the 'accepted' design pattern is for losers. Why bundle myself in with them? Perhaps I'm not following established patterns in this system because I don't need that extra step here. The scope of this change might change in the future but I'll deal with it then. Again, there's that little voice telling you to just get it done now. Otherwise, before long, every other module in the system is some kind of 'exception'. We end up with something that's difficult to understand, even though each change was only a small deviation from the norm.

So in essence...if you've ever thought something like this, then that's my point made for me. Even if you're fine with pacifying the code angel on your shoulder, you already know what unclean code is. The little voice is either trying to bring you back to the light. Or it's just you trying to convince yourself that it's ok to be breaking with pattern. Hey, I'm not going to argue that there aren't legitimate exceptions. I'm just saying let's call a spade a spade, unclean code is unclean code which will start causing problems down the line if not addressed.

If you've never had something like this go through your mind, maybe you've only ever written clean code. Bravo! Or, maybe you're a less experienced developer that isn't as in touch with why it's important yet. Keep at it. Perhaps you've never had the temptation to break pattern to get something done faster. My point all along has been that whilst the specifics of coding standards are written about and debated a lot, it's all a bit superfluous. We don't need the Wizard of Oz to give us a brain because the answer was inside us all along.

Let me know of your experiences

So to that end, let me know of your experiences. Does your self-conscience flutter a bit when you're committing a change with a 'cheat' in it? Does the intuition about clean code inspire you not to take shortcuts? Do you take part in the debate or do you wish everyone would shut up about it? Get in touch and let me know. Happy clean coding!

-tommy