7 reasons why clean code is important
When I graduated from college, I was a lousy programmer. I had a degree and a lot of book knowledge, so I started a side project and spent hours hacking every night. Things started off well, but my coding style did not do me any good. I copied and pasted, chose bad names, mixed misgivings, and periodically created long-term functions that did a variety of loosely related tasks. And after a few months, I came to a hard conclusion: the project collapsed under its own weight. I thought I could handle being sloppy because I was the only developer. But in the end I had to admit that I could not sustain, let alone understand, the chaos that I had made!
While my code was generally good, I made programming mistakes because I wrote code that nobody else could understand without careful refactoring. I was a highly efficient technical debtor. You do not want to be one of these.
What is clean code?
Clean Code is a reader-centric style of development that creates software that is easy to write, read, and maintain. Developers are often tempted to consider their work complete when the application works as expected. But we do not just write code for computer usage.
Programming is the art of telling another person what the computer should do.
The clean code is about recognizing that your audience is not just a computer, but real people! Considering this principle, let’s look at seven simple reasons for clean code.
1. You are an author
Do you want to impress your mother? Tell her you are an author! An author is someone who practices writing as a profession. Developers write all day. As a developer, it is easy to forget that every line of code we write is likely to be read 10 or more times by humans. These people are our colleagues. You are busy troubleshooting and adding features.
Great writers are known for writing books that tell a clear, compelling story. They use tools such as chapters, headlines, and paragraphs to clearly organize their thoughts and guide their readers painlessly. Developers work in a very similar system but simply use different specialized languages of namespaces, classes, and methods.
Clean coders use these tools wisely to control complexity and tell a clear story.
2. It is fundamental
In recent years, software practices such as professional refactoring, component testing and TDD have attracted much attention. These approaches increase code quality and maintainability. Implementing clean code principles is a basic skill that pays off when it comes time to redesign code or test code. Clean code principles lead to source code that is very modular and thus easier to read and to test. If you think of these practices as part of a house, clean code is the foundation.
3. Justify your technique
Imagine sitting in a technical interview. If you are asked about your code quality, could you provide a professional and rational justification? Or would you be?
If you can say more about writing clean code, this is a bad sign. If you have not considered the quality of your coding style methodically, there are likely to be many ways to improve it. Who writes clean code, can convey many concrete activities, patterns and techniques, with which he keeps his code clean. Clean code does not happen randomly. It requires a conscious and regular focus to clearly communicate the intention.
What is measured is managed.
— Peter Drucker
Creating a vocabulary of clean code is not only useful for interviewing and improving your own code quality. In addition, the introduction of a common vocabulary and a framework for understanding the readability of code promotes entertaining conversations in code reviews.
4. Reading is hard
Developers are often proud of their ability to solve difficult problems. However, writing code is relatively easy. Reading is hard. Because of this, so many developers are more likely to read the existing code than to read and understand it. Since the reading code is inherently challenging, you will not be able to understand the code later if you write code that you can barely follow while writing. Professional developers write so much code that after a few weeks of separation most of the structural and design decisions go out of memory. It’s like looking at the project from a new perspective. If you can not understand your own code a few weeks later, this can be a really depressing situation. Trust me, I was there.
5. The technical debt is depressing
Writing sloppy or confusing code causes technical problems in our projects. While technical debt can be useful if carefully considered in context, excessive technical debt is depressing and drives talent out of the organization. When the simple things get difficult, the developers will vote with their feet and go somewhere else. Developers achieve more job satisfaction from the quality of their work than from quantity. The technical debt reduces the reuse probability and sets a low value for the rest of the code base.
6. You are lazy
Larry Wall, the author of the programming language PERL, said the three great virtues of a programmer are laziness, impatience and hubris. Yes, laziness can be a positive trait in the right context. When I stumbled upon writing code in my early years, I learned how difficult it is to write clean code. Professional developers are anxious to be lazy. This laziness is based on paying special attention to the code, so it’s not that hard to write in advance, and it’s easier to work with later. Writing clean code does not take long. And as soon as you understand the principles, you can actually code faster, as it’s easier to manage the scarce, expressive code that performs a function.
When you’re under pressure, cutting corners and ignoring best practices is tempting. As Uncle Bob Martin reminds us in his book “Clean Code,” we have no time to be sloppy. Being sloppy ultimately slows us down due to higher error rates and later maintenance costs. History has shown that it is unlikely that you will find time to clean later. So why not right the first time?
7. Do not be a verb
Okay, the other reasons are solid, but this is the key point: Everyone knows the previous employee whose name became a verb describing dirty code.
“Oh man, this code became Jimmy’d.”