An Episode of Clean Code

5 min readApr 5, 2021

Hello there, welcome to an episode of Clean code! In this episode, we will talk about everything you need to know about applying the clean code to your code, of course.

For starters, let’s talk about what clean code is and what makes it so “clean.” As Robert C. Martin stated in his book Clean Code: A Handbook of Agile Software Craftsmanship,

“Clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.”

there is also another quotation from Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language:

“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”

You will notice that a written code is a lot more than just a working code from the quotes above. It has to be simple, elegant, efficient, and many more adjectives you can find in those quotes. You might be thinking, “Why should I care?”

Well, you should. Because the code you write is rarely just be written and forgotten. There might be times when you or other people need to work on the code, and you need to understand the code well to work on it again. If you write clean code, then you are helping yourself and your co-workers in the future.

Characteristics of Clean Code

Based on the definitions and experience, these are the characteristics of clean code:

Simple: The code follows the Single Responsibility Principle (SRP)
Elegant: Pleasing to read
Readable: Easy to read
Testable: Run all the tests

Next, we will see how to write the clean code based on these characteristics and definitions above.

How To Write Clean Code

Meaningful Names

Write meaningful names for every variable, function, argument, class, module, and everything. We should choose a name that specifies what is being measured and the unit of that measurement. It may take some time to think about good names, but it actually helps to make your code better and more understandable in the future. To help you decide on names, here’s a hint. Choose a name that can describe well what it does and how is it used. If it still needs a comment for an explanation, maybe you’re doing it wrong.

Example:

Use intention-revealing names
Pronounceable
Searchable

# good
today_timestamp = Time.current

Don't

Unpopular acronyms
Using confusing letters for names

# bad
today_ts = Time.current
t= Time.current

Functions

To write clean code for functions, the first thing you need to pay attention to is that the function should be small. And the next rule is, they should be smaller than that.

Looking back to the characteristics, the function should be following the Single Responsibility Principle, which means that the function needs to only one thing. Here are some tips to make your functions cleaner:

Use less than 3 arguments
Don’t do code duplication (DRY — Don’t Repeat Yourself).
Use descriptive names

Comments

This one is easy, do not comment on your code. If your code needs commenting, then maybe you’re doing something wrong. Ideally, the code doesn’t need comments and should be self-explanatory. Correct naming can prevent comments.

Code Organization & Formatting

Another aspect you should be paying attention to is how your code formatted and organized. Well-organized code will look a lot more cleaner! Here are some tips on how to organize and format your code:

Group code by their functionality, the related function must be close.
Make sure the code is ordered as of the calling sequence. The caller before the callee.
Avoid too long files. 1000–2000 lines are okay.
Follow proper indentation across code files.

Exception Handling

In writing code, we need to realize that there are cases that can go beyond what we have planned and we need to handle those as well. This is called exception handling, where we put implementation on other cases that may happen and cause errors. Here’s an example:

The code contains a case where the interface gets empty data so that it doesn’t cause an error but presents other text.

Unit Tests

Unit test code is as important as the production code. Besides making your code clean, it also helps your code become more maintainable. One of the things you can do to your code is to apply The Test Driven Development (TDD). In the Clean Code: A Handbook of Agile Software Craftsmanship, there are three laws for TDD:

Don’t write production code until you have written a failing unit test
You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Don’t write more production code than what is sufficient to pass the failing test.

Here’s an example:

These tests are used to check the copy of a page’s user interface. As the law says, write the failing code first before you write the implementation. So you wrote these test and push to the repository to get the failing result (red), and then you can start writing the implementation code to get green result.

More explanation about this will be on the Test-Driven Development topic article later, stay tune!

It may take some time to get used to getting clean code applied to your code. But start doing it! It’ll make your code better and more maintainable, and also make you a good programmer😉

See you on another episode!