Clean code matters. Making sure that every single line we write is as top-notch and clean as possible makes a huge difference, especially in the long run. And when we talk about clean, we mean sustainable. Does our code withstand time and different scenarios?
Measuring what is clean and good code might be hard, but some of you might have heard about the “WTF rule”. While reading somebody else’s code, how many times per minute do you think “WTF?”. So if we use this measurement in checking if code is clean, let’s go over a couple of the most important methods for cleaner coding.
“ I like my code to be elegant and efficient” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Readability
Most of the time instead of writing code, we read code. That is the single most important reason to make sure our code should be easy to read. Efforts put into making code easily readable pay itself back multiple times because of maintainability and fewer errors.
You can think that any code you write will be read by somebody that doesn’t know exactly what you were aiming for in the first place. So try to make it so that those people could easily glance at your code and have an understanding of what the code is doing.
So what are the usual obstacles to clean code?
Short answer: time. Schedules are usually too strict for efficient coding, and to make sure that projects are on time people usually cut corners. Just think how many times you thought to yourself “I could have done this better but I just don’t have time to fix it?”
We also tend to want to move into other (usually interesting) stuff quickly. Re-reading and fixing your code isn’t the most fun thing to do, but it usually is worth it. We might also think that our creations are fragile, and if we go poking them, they might break. But especially at that point, redoing things smarter would be a top priority! Refactor people!
DRYKISS
What is DRYKISS? Don’t repeat yourself and keep it simple stupid. Don’t just blindly copy-paste code, but always pay a second thought to the function you’re trying to achieve. Copy-paste turns into repetition easily, and you could have most likely done that in one function and the code would be more simple that way.
While keeping it simple, you might as well keep it short. Let’s say you’re trying to achieve one single thing and you wrote ten lines to do it. Do those ten lines just do one thing? Maybe it does something else as well? Keep it simple, and try to make shorter functions and the code becomes simpler almost automatically.
We have to mention good planning as well. Well planned is half done. Complex structures are hard to comprehend, and if you don’t have a fleshed-out plan the understandability is even harder. Mind Maps and charts usually help out A LOT, and at that point, it really gives you a chance to simplify even before writing a single line.
If you follow all of the guidelines written above, your code should be so simple and understandable it might not need commenting. Clean code is self-explanatory, and less commenting than normal is needed. Commenting has its hazards, such as writing false comments by accident, and those hazards are eliminated with clean code.
