Confession: When I graduated college I was a lousy programmer. I had a degree and plenty of book knowledge, so I started a side project and spent hours nightly hacking away. Things started off fine, but my coding style wasn't doing me any favors. I copied and pasted, chose poor names, intermixed concerns and regularly created long run-on functions that performed a wide variety of only loosely related tasks. And after a few months, I came to a hard realization: The project was falling down under its own weight. I thought I could get away with being sloppy since I was the only developer. But ultimately I had to admit that I couldn't maintain - let alone comprehend - the mess I'd made!

While my code generally ran fine, I was committing programming malpractice because I was writing code that no one else could likely comprehend without careful refactoring. I was a highly efficient technical debt generator. You don't want to be one of these.

There's no problem so simple that a bad developer can't make it complicated.

Steve Bohlen

Ouch, was Steve talking about me? My early creation was certainly a proof of this maxim. Even the simplest logic can be very confusing if not written well. These early experiences convinced me that I needed to investigate approaches to improve my coding style.

What is clean code?

Clean code is a reader-focused development style that produces software that's easy to write, read and maintain. Developers are often tempted to consider their work complete when the application operates as expected. But we're not merely writing code for computer consumption.

Programming is the art of telling another human what one wants the computer to do.

Donald Knuth

Clean code is about recognizing that your audience isn't just a computer, it's real-live humans! With this principle in mind, let's review seven simple reasons clean code matters.

1. You're an author

Want to impress your mom? Tell her you're an author! An author is someone who practices writing as a profession. Developers write all day. Yet as developers, it's easy to forget that each line of code we write is likely to be read 10 or more times by humans during its lifetime. These humans are our fellow co-workers. They're busy fixing bugs and adding features.

Great authors are known for writing books that tell a clear, compelling story. They use tools like chapters, headings, and paragraphs to clearly organize their thoughts and painlessly guide their reader. Developers work in a very similar system, but simply use different jargon of namespaces, classes, and methods.

Clean coders use these tools wisely to manage complexity and tell a clear story.

2. It's foundational

In recent years software practices like professional refactoring, unit testing and TDD have received a great deal of attention. These practices elevate code quality and maintainability. Implementing clean code principles is a foundational skill that pays off especially well when it's time to refactor code or bring code under test. Clean code principles lead to source code that's highly modular and thus easier to read and test. If you think of these practices as part of a house, clean code is the foundation.

3. Justify your technique

Imagine you're sitting in a technical interview. If you're asked about your code quality, could you provide a professional and rational justification? Or would this be you?

If that's all you can say about writing clean code, that's a bad sign. If you've never methodically considered the quality of your coding style, there's likely plenty of opportunity for improvement. Those who write clean code are able to convey many concrete activities, patterns and techniques they use to keep their code clean. After all, clean code doesn't happen by accident. It requires a deliberate and regular focus on clearly conveying intent.

What gets measured, gets managed.

Peter Drucker

Building a vocabulary around clean code isn't just useful for interviews and elevating your own code quality. It also fosters level-headed conversations in code reviews by establishing a common vocabulary and framework for discussing code readability.

4. Reading is hard

Developers often pride themselves with their ability to solve difficult problems. However, writing code is relatively easy. Reading is hard. This is why so many developers are tempted to rewrite rather than do the hard work of reading and comprehending existing code. Since reading code is naturally challenging, if you write code that you're barely able to follow as you write it, you'll find you're unable to comprehend it all later. Professional developers write so much code that after a few weeks of separation, most the structure and design decisions fall out of memory. It's like looking at the project with a fresh perspective. Not being able to understand your own code a few weeks later can be a really depressing situation. Trust me, I've been there.

5. Technical debt is depressing

Writing sloppy or confusing code injects technical debt into our projects. And while technical debt can be useful when carefully considered in context, excessive technical debt is depressing and drives talent away from the organization. When the easy things become hard, developers start voting with their feet and go elsewhere. Developers derive more job satisfaction out of the quality of their work than the quantity. Technical debt decreases the chance of reuse and sets a low bar for quality throughout the rest of the code base.

6. You're Lazy

Larry Wall, author of the PERL programming language said the three great virtues of a programmer are laziness, impatience and hubris. Yes, laziness can be a positive attribute in the right context. As I stumbled through writing code in my early years, I learned the hard way that writing clean code really pays off. Professional developers strive to be the good kind of lazy. This laziness is based on putting extra care into the code so that it's not so hard to write up front, and it's easier to work with later. Writing clean code doesn't take any longer. And once you grasp the principles you can actually code more quickly because terse, expressive code that does one thing is easier to manage.

When under pressure, it's tempting to cut corners and ignore best practices. However, as Uncle Bob Martin reminds us in his book "Clean Code", we don't have time to be sloppy. Being sloppy ultimately slows us down in the long-term due to the increased frequency of bugs and the long-term costs of maintenance later. History has shown it's unlikely you'll find time to clean it up later, so why not do it right the first time?

7. Don't be a verb

Okay, the other reasons are solid, but this one is the clincher: Everyone knows the previous co-worker whose name became a verb to describe dirty code.

"Oh man, this code has been Jimmy'd."

Ouch. Comments like this are the kiss of death for long-term employment prospects. We want our co-workers to recommend and hire us in future positions, right? Being known for writing clean code is a great way to assure your co-workers recommend you and look forward to working with both you and your code in the future.

Clean code principles

There are three core principles to writing clean code:

1. Choose the right tool for the job
2. Optimize the signal-to-noise ratio
3. Strive to write self-documenting code

Cory's new Pluralsight course Clean Code: Writing Code for Humans explores each of these principles in detail. If you're interested in elevating your code quality and establishing a vocabulary for evaluating and writing clean code, give it a look!

Ready to test your skills in Compiler Design? See how they stack up with this assessment from Smarterer. Start this Compiler Design test now.