From the perspective of a Frontend Developer
I am a qualified Frontend Developer and work at IONOS as Community Relations Manager, where I am responsible for Developer Relations. For years, I have been observing that the topic of clean code is becoming relevant again and again, which is why I am sharing the experiences I have had with it.
JavaScript is one of the most popular programming languages in the world, and for me as a Frontend Developer, JavaScript has become indispensable. The scripting language, which is often associated with interactive websites, makes it possible to create dynamic websites, control user interactions and develop modern web applications.
Anyone who has worked with this programming language knows how important it is to be able to understand your own code or the code of others. For me, writing so-called clean code is therefore an essential skill that you should master. At the latest at the next code review or for a new project with a new development team, the question will come up at some point: What does clean code actually mean to you?
Why is clean code important to me?
After more than 5 years of working from home, I have personally realized how important clean code is in a software project. Short-term agreements within a team are becoming more and more complex, as the daily routine is characterized by more meetings due to physical separation. Pair programming with a face-to-face exchange is taking place less and less frequently, and code reviews are also shorter and reduced to the essentials. Whereas face-to-face meetings can sometimes go into more detail and provide further impulses.
My criteria for clean code
Readability and comprehension
Clean code is particularly important when it comes to the readability and comprehensibility of the code. If I work in a team, I have to make sure that my code is readable and understandable for all team members so that collaboration can work smoothly. There’s nothing worse than when the next code review only raises questions about the code you’ve written.
Example: Meaningful and readable variables
❌ Difficult
“foo”, for example, is often used as a placeholder in programming if you don’t have a suitable variable name to hand. Make sure you avoid this at the productive level.
const foo = moment().format('DD.MM.YYYY');
✅ Better
Use names that are meaningful and that people know immediately what they are talking about. Programming languages are international, so everyone should be able to read your code, so make sure you use English words for your variables. This applies not only to variables, but also to functions.
const CURRENT_DATE = moment().format('DD.MM.YYYY');
Maintainability
Another point is the maintainability of my written code. The more complex the code, the more time-consuming maintainability becomes, as it becomes more difficult to identify and rectify errors. If the requirements change, it is also guaranteed that every team member can find and change the part to be changed more quickly. Maintainability is essential for large projects. Due to the large amount of source code, you can quickly lose track of things and no longer find your way around your own code.
Example: Searchable variable names
❌ Difficult
In this example, it is not clear what this high number means. Make sure you give it a searchable name.
setInterval(close, 86400000);
✅ Better
Constants, in this case “const”, allow you to assign fixed and non-overwritable variables. Perfect for the fixed milliseconds per day. These constants are always capitalized and written in snake case. Always name them so that you can find them again in the future.
const MILLISECONDS_PER_DAY = 86400000;
setInterval(close, MILLISECONDS_PER_DAY);
Example: Array methods
❌ Difficult
In my opinion, the For loop is one of the most frequently used functions in JavaScript and, as you can see from its structure, it is also very error-prone. In addition, the For loop also returns the empty fields in an array. This can lead to confusion, as you always have to check carefully that no errors have occurred during iteration.
const studentsGrades = [3, , 1, 2, , 2, 5];
for (i = 0; i < studentsGrades.length; i++) {
console.log(studentsGrades[i]);
}
//Output: 3, undefined, 1, 2, undefined, 2, 5
✅ Better
If you use the predefined array methods, the “forEach” function is the best choice for the same example. This shortens the regular For loop and also automatically does not output the empty fields. The readability of the code also plays a very important role here.
const studentsGrades = [3, , 1, 2, , 2, 5];
studentsGrades.forEach((studentGrade) => {
console.log(studentGrade);
});
//Output: 3, 1, 2, 2, 5
Professionalism
In my opinion, writing clean code also demonstrates professionalism. Those who value high quality also show this in their code and at the same time take care of high-quality software. Clean code therefore also acts as a business card.
Conclusion
Writing clean code not only helps you, but also your team and is essential for every software developer. The examples above are based on my experience and are only intended as a guide. It is only a fraction of what is possible with clean code.
Writing clean code should not be a one-time process. You should want to continuously improve and simplify your code so that it always remains readable and maintainable. The more often you deal with the topic, the better and faster you will write your code in the future and the easier it will be to collaborate with your team.
Top comments (4)
The problem with all of this is: who decides what's readable, comprehensible, maintainable.... ? These things are all completely subjective.
Over the years, I've seen an increasing trend of all of this being taken too far...
Preaching 'Clean Code' is Lowering the Quality of Developers
Jon Randy 🎖️ ・ Jun 25 '22
Hey Jon.
thank you for your reply.
Yes, there is the big question about who defines all these kind of things.
And I basically have one answer: The Team.
Clean Code as it is, can be really stressful when you go beyond and you take it too far. And as you mentioned in your article, it can lower quality of a developer itself.
But as I mentioned, when you working in a Team you should write your code as readable, comprehensive and maintainable for your Team, not just for yourself.
Yes we can argue with: "When someone cannot read my code, he or she must learn how to code properly". But in that case we will lose time. And time equals money ;-)
So that’s why I mentioned, that when you are in a team, you should define it as a team.
Not every rule of Clean Code is the perfect rule for your team or yourself.
Thanks for explaining - great article!
Very helpful article!