Clean Coding: Step One
First and foremost, I must state that this article is not a document in which a master programmer instructs you, but rather a collection of notes gathered by a software developer throughout the development period.
The biggest difference between a competent programmer and an average programmer, in my opinion, is how hard you push yourself. Until recently, I had been a fairly average coder.
Although hearing about pushing oneself in an article about “clean code” or “simple code” may not be pleasant, I’ll attempt to clarify.
Rather than pushing myself to achieve better, I always strive to accomplish things in the most’simple’ way possible. The first thing that comes to mind is writing as quickly as possible or compressing the code as much as feasible.
Is this “simplicity” I’m referring to true?
Do you create code in a “simple” style, despite the fact that there are thousands of articles and hundreds of tutorials on the subject and the world’s best-selling software books are in this field?
Do you have any idea what a clean code is?
Let’s give the floor to the author of the clean code book that perhaps every software developer has in some way.
Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many
ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be
literate since depending on the language, not all necessary information can be expressed clearly in code alone.Robert C. Martin
The code is independent of your operating environment, programming language, and industry. Not all code is considered clean; nonetheless, it is obvious that clean code is simple code that does not become more difficult when more is added. It should be short enough to not impair legibility while yet being lengthy enough to eliminate the necessity for a comment line. It is not clean code if it necessitates the inclusion of a comment line.
“Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.”
Robert C. Martin
Irregular code increases technical overhead and is inconvenient to use. It’s tough to say whether a piece of code is operating appropriately or incorrectly. Dirty code took up too much of our development time.
It is not mutually exclusive to be clean with high-performance code or secure code. Your code’s performance and security will suffer if it is not written in an easily comprehensible and adaptable format. The high performance of a code with low readability will lengthen the time it takes to solve a future problem. Does it make sense to prefer this structure that is not clean but performant? In reality, the cleanness of the code should be prioritized for efficiency and security, and it should be regarded a need.
Your code must be intelligible, adaptable, extendable, and maintained in order to be clean.
Code that is simple is succinct and standard. It is appropriate for the architecture of the project.
The code’s simplicity is determined by how it’s titled, what language it’s written in, and how it’s documented.
Non-repetitive code created for a specific job is referred to as focused code. It does not include anything but the task that will be done. It is neither too lengthy nor insufficiently short.
Correct code is code that has been tested and validated.
“Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.” Robert C. Martin
“Clean code always looks like it was written by someone who cares.“ Robert C. Martin
Writing clean code should become a personal habit rather than developing by adhering to certain rules. I think it’s similar when a doctor doesn’t care for his patient during surgery and a programmer doesn’t care about code during software development.
“To write clean code, you must first write dirty code and then clean it.” Robert C. Martin
Let’s look at some examples of terrible code, why it’s bad, and how it may be improved. Let’s get a sense of what we’re trying to address.
If you look at the code I supplied above, you’ll notice how much readability and clarity can be gained simply by properly naming variables. Use names that are easy for people to comprehend since the machine will understand and apply any name you give the variables.
You should take care to write codes that your teammates working with you or those who will come after you can read and understand.
The expressive code does not require any comments: We utilize comments to compensate for our failure to communicate in code.
Use code instead of comments to describe anything.
What is the purpose of the code above?
What are the benefits of finishing all of the work in a 15-line area?
Make sure your code is brief, not redundant, and organized in a way that does not do many tasks at once. Doing one thing well will save you a lot of time compared to doing four chores in a shambles. Similar teachings may be found under the Single Responsibility portion of the ‘Solid principles’ section, as well as other software concepts.
Anyone can write bad code, but it’s up to you to fix it and deodorize it.
You wouldn’t want anyone to curse behind your back, would you?
Bad code is complex, difficult to change, highly dependent, repetitive. I know I’ve written code like this before, but it’s pretty hard to learn to write good code without writing bad code. I’m taking the first step, I’ll start running slowly. I’ve been writing dirty code for two years and now it’s time to clean up.
Since all of Robert C. Martin’s words sounded right, I added many sentences from him, I will start reading different software developers while I continue to write clean code.
