Bad code works until it's the year 2,000. Bad code is difficult to understand, more complex than it should be, not easy to test, and it makes other developers seethe with frustration. While it might take longer to write clean code in the short term, it's beyond established that writing clean code will save everyone time, effort, and ultimately money.
But there's always room to learn. No one writes clean code from the beginning. Here are six of the most important principles to keep your code clean.
(Side note: Clean code doesn't rely on language-specific rules. Instead, it relies on language-agnostic principles agreed upon by the developer community. As such, these principles are applicable to almost every programming language)
Clean Code Principles
KISS: Keep It Simple Stupid. A design principle originating from the U.S. Navy that goes back to 1960 already. It states that most systems should be kept as simple as possible (but not simpler, as Einstein would have said). Unnecessary complexity should be avoided. The question to ask when you're writing code is "can this be written in a simpler way?"
DRY: Don't Repeat Yourself. Closely related to KISS and the minimalist design philosophy. It states that every piece of knowledge (code, in this case) must have a single, unambiguous, authoritative representation within a system (codebase). Violations of DRY are referred to as WET: We Enjoy Typing, Write Everything Twice, Waste Everyone's Time.
YAGNI: You Aren't Gonna Need It. A developer should not add functionality unless deemed necessary. YAGNI is part of the Extreme Programming (XP) methodology, which wants to improve software quality and increase responsiveness to customer requirements. YAGNI should be used in conjunction with continuous refactoring, unit testing, and integration.
Composition over inheritance: Not an acronym, sadly. It's a principle where you design your types over what they do instead of over what they are. It's explained in more detail in this video. One of the ways to implement this principle is with the Object.assign() method in ES6.
Composition is favored over inheritance by many developers, because inheritance forces you to build a taxonomy of objects early on in a project, making your code inflexible for changes later on.
Favor readability: It's not because a machine can read your code that another human can. Particularly when working with multiple people on a project, always favor readability over conciseness. There's no point in having concise code if people don't understand it.
There are many ways to make your code more readable. Two examples are placing common numbers into well-named constants (e.g. const CACHE_TIME = 200;) and creating long names instead of shorter ones (e.g. userHasFormAccess over canAccess, which doesn't tell as much).
Practice consistency: This is arguably the overarching principle of all clean code principles. If you decide to do something a certain way, stick to it throughout the entire project. If you have no choice but to move away from your original choice, explain why in the comments.
Of course, this is by no means a comprehensive list. There's so much more to clean code. In fact, if you want an excellent book on clean code, I can recommend The Art of Readable Code by D. Boswell and T. Foucher.
What are some of your favorite clean code principles?
Top comments (9)
I am a huuuge fan of Uncle Bob and I believe that everyone should watch his course or read his book on Clean Code.
Just to give you a taste:
Where can one watch his course?
Great list!
Doesn't KISS stand for "keep it short and simple"?!
I think "Keep it simple stupid" works better - since, sometimes - keeping it simple warrants more code.
There are a few variations
This article tells us to leave Java.
The hidden message
I love the cartoon in the article. The right side is basically me talking to myself the day after I write some code and then read it again. :D