How to Write Clean Code: Part I

DZone 's Guide to

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.

· Agile Zone ·
Free Resource

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

If you are choosing to write HTML code with script injection, then you are doing it terribly wrong. JavaScript is a tool for storing markups. SQL code should be separate from your business layer and injecting it to the same layer will make you embarrassed, even in front of recent college grads. It is important for you to ensure that you code in the layer it matters. Never write HTML injection in the service layer and don't try to overboard by using hacks. Hacks give immediate relief for the pain, but do the hacks only if you have more affinity to pain in the end.

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.

agile ,clean code ,coding

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}