Sterilize Your Code

[Its finally time…]

Not all codes can be classified as what we call a Clean Code. So, what exactly counts as a clean code? Well, to be frank clean code is quite subjective and every developer has different views on what counts as a clean code. Although there are some ideas that they call the best practices, but there is no definitive way to describe a clean code. If I would give it a general kind of description of clean code and also summarize it in a sentence, it would be:

Clean code is a code where everyone can easily understand it and change it

This would mean that no matter who reads the code they would understand the flow of the entire code, what each class does and know how different objects work with each other. The code would be less of an infuriating read and more of an pleasing read to the readers.

Why Care?

After knowing what clean code is, why would you care about it? A simple answer would be that the code you’ve made would not always be seen by only you. Other people who are collaborating with you would also need to understand your code so that they could easily add changes to the code without always going to you to ask “What is this object used for?” or “What does this method do?”. You might think it would be fine for them to ask questions about your code, but if they have exactly zero understanding of your code their questions would get very old real fast and would annoy you instead. No one would want that right? With clean code, you would have shaved quite the amount of time that would normally be spent by your co-workers mulling over your code and wasting your time with questions. Hence, clean code would also effectively increase productivity.

Then what if you don’t have collaborators? Do you still need to implement clean code? The answer to that would be a resounding YES! Clean code would most definitely make you life easier, since you would not need to take long to realize what object ‘d’ does. Even though you made the code does not mean that you would always know what each dirty code is. We are all but flawed human beings and not machines. Clean code helps us write like one.

So How Do We Do It?

As I’ve mentioned previously, although there is no exact definition of clean code there are some best practices. Here I shall talk about those best practices, but first I would like to introduce some Clean Code Principles.

• KISS, Keep It Simple Stupid. You do not need to make everything unnecessarily complicated, strive for simplicity by asking “can this be written in a simple way?”.
• DRY, Don’t Repeat Yourself. Everything should have ONE clear representative.
• YAGNI, You Aren’t Gonna Need It. You should not add functionality that is not going to be used right away.
• Composition over inheritance, design based on their use and not what they are.
• Favor readability, write in a way so that other people would understand it.
• Practice consistency, if you decide to do things a certain way try to keep doing it throughout the code. If you can’t then comment on it so no one would be confused.

So with that out of the way, what are the best practices that counts as a clean code? Well here are some practices that you can do to at least be able to write a clean code.

• Use easily understood names for variables and methods. Some of you might feel a bit lazy while typing codes and tend to abbreviate variable. Avoid those habits.
• Use name to show intention. Instead of naming object or methods with one letter, such as d or n, name it as what it does.
• Don’t be innovative, be simple. Your code is not the place where you can be all clever, especially regarding naming. Use names that all can understand and don’t make it an inside joke.
• Be consistent.
• Use a consistent naming conventions. There are multiple ways on doing this, such as the camelHumpMethod or ANY_OTHER_METHOD.
• Make the functions clearly understood. Keep them as short as possible, an ideal length would be around 15–20 lines but it could go longer so long as the code is kept clean.
• Keep arguments less or equal to three.
• Don’t comment on code. If your code needs to be commented its explanation, refactor your code.
• Don’t repeat code or hard code if possible.

Those would be some practices you can apply by yourself to creating a clean code and you go. After finishing the code, you might also want to review the code by yourself and then review it with your colleagues. This would give you more insights and suggestions that you or you colleagues can bring up during the review process.

Conclusion

As you can see, clean code is quite important because it increases the readability of your code. It would not matter even if you code for yourself, there would be times where those abbreviations and dirty naming conventions would be lost to you. Clean code does not only benefit those who would read your code but also yourself, since… you also read your code. There also exists another way of completely sterilizing your code, namely by using TDD but that would be a topic for another time.

That would be all for me regarding the clean code. Next, I planned to cover the topic of TDD, but that could be changed. I should see you all in TDD…probably.

Goodbye for now my children…