How to Write Clean Code: Part I
How to Write Clean Code: Part I
In this article, the author explains the importance of writing clean code and provides four different ways to be sure that yours is clean.
Join the DZone community and get the full member experience.Join For Free
We're always talking about writing good, clean code according to best practices and standards, but do you ever ask yourself, "Is my code really good?" If you haven't, then most likely your code is not at all good. Most of the time, we are proud of our ability to solve problems, but if you are not articulating thru proper art of authoring your code then you will never be appreciated for what you have written. Code is not just for computers but also for your fellow developers to understand. If you have not done it properly, then during support, a lot of effort will be put into cleaning up your code.
Computers can understand code written by idiots of any culture but what's important is to ensure that anyone who can read code can understand your code.
It's always misunderstood that speedy development means bad code and more times means good code. That's completely wrong. Speed has no mathematical equation to make your code look bad; please get the hell out this misconception! If you would like to be called a professional developer, then it is very important that you author beautiful code (no, you are not going to use colors or italics or bolding). Dirty code means more noise that interrupts and reduces the quality of the good music. Here are some ways to write the best possible code.
Follow Some Principles and Don't Compromise
Choose the editor and accessories that matter to you. It is very important to not abuse what you like. The minute you do that, you have done damage that can't be repaired. Learn through examples and experiences that you and others have had. Choose the right tools and techniques that ensure that you won't deviate from authoring the best code.
Layer It So You Know What to Write Where
Separation of Responsibility
Your code should tell what it is doing and express this very clearly. You don't want to end up putting more citations about what the code is going to do. Ensure that your code does one thing and not too many things. Break code into pieces so that every unit understands what it should be doing. Your desk becomes messy over time, not on day one; it's the same with code. Put in the effort to keep it up.
DRY (Don't Repeat Yourself)
This principle is something taught on the day one of programming that don't repeat yourself. The idea behind this is that a piece of code doing the same thing should be written only once. This is simple and doesn't need more explanation. If you are copying and pasting code, then you are repeating. Apply this idea alone and you will end up writing good code. The intention is that if you don't repeat yourself, then you will fix code issues and not repeat code fixes.
If you follow the above four principles, then you have authored code in a best possible way. Write the code as if others are going to read it (computers understand it, but your peers, boss, clients, etc. read it and will have no patience to solve your code puzzle).
Stay tuned! In my next blog, I will take on the practices of writing classes and functions, declaring variables, following design patterns, and more.
Opinions expressed by DZone contributors are their own.