Wow, Clean Code.

Ihwan Edi Saputro
Akhirnya
Published in
5 min readApr 14, 2020
From https://collinmbarrett.com/clean-code-1/, this is not an advertisement article btw.

If you are a programmer or at least have tried coding, did you agree that “1 error solved, 1000 errors grow”? I’ve ever experienced this statement many times, although it's not exactly 1000 errors. The very common problem for me, and maybe for you guys, are when we solved one problem or bug in a function, it just made another error in another function, and yeah, 1 error solved, 1000 errors grow.

Another problem that we may ever experience is, our coding is really not readable for other people (even ourselves sometimes can’t read our code) and it’s really difficult to do debugging when we have an error(s). And the last that I will mention here is, when we created a very large program, sometimes our program is really wasteful. So much resource and time, which should be used for another program, just being used for our program.

Our too much duplicate, low cohesion, and high coupling code can be called as Dirty Code. Imagine when you are going to repair the inner part of your Hardware, for example, CPU, and you’ve got that inner part very dirty, so much dust, and even a net spider. It must be easier for us to repair our inner part of our CPU if that inner part is clean. You can see which part that has been malfunction more clearly than when that inner part is dirty. Yes, let’s talk about Clean Code.

Clean Code? What? Is it Useful?

Of course, Clean Code is the opposite of the Dirty Code. More readable, low coupling and high cohesion, and also optimized resource and time code. I think it’s better for all programmers to get used to creating a Clean Code from the beginning of the development, rather than trying to cleaning the code when the time is near the deadline.

Is it useful? Absolutely yes. Let’s see some benefit of Clean Code below:

Easier Debugging

It is almost impossible for everyone to write a program (not just a “Hello World” code 😆) that has no error at all. Dirty or Clean, we will still encounter some errors. But, Clean Code will make it easier to debug as it easier to read and understanding, which part contains an error, and doesn’t make too much change as we fix the error(s).

Better Use of Your Time

The easier the debugging, the less time needed. We don’t need to waste more time trying to understand which part contains an error and why this error happened. Another problem is, when we are working on a project, it’s easy to forget things you did in the code, especially when your client comes back with changes. Clean lines of code make it easier to make changes and also reduce production time.

Feeling Good, Like I Should, Went and Took…(Surfaces — Sunday Best)

This time is 2020, I just take a bit of the music that represents this point 😆. If you are writing quality, clean code, you should feel super confident. You will enjoy explaining all of your code to your friends, colleague, clients, and other people. You will not afraid if there is a bug as you will find it easier and faster to debug it.

How to Make it?

I am glad that I need to write the Clean Code article for my Software Project course assignment, so I can learn more about Clean Code. I will try to explain what Clean Code really is with some points on how to make it according to some source. You can see it in the reference section below.

Use meaningful and pronounceable variable names

Remember, you want to create a code that is readable to other people (and to you). You want a code that is easier to understand so you need to create meaningful and pronounceable variable names.

Bad

ymdstr = datetime.date.today().strftime("%y-%m-%d")

Good

current_date: str = datetime.date.today().strftime("%y-%m-%d")

Avoid Mental Mapping

Don’t force the reader of your code to translate what the variable means. Explicit is better than implicit.

Bad

seq = ('Austin', 'New York', 'San Francisco')

for item in seq:
do_stuff()
do_some_other_stuff()
# ...
# Wait, what's `item` for again?
dispatch(item)

Good

locations = ('Austin', 'New York', 'San Francisco')

for location in locations:
do_stuff()
do_some_other_stuff()
# ...
dispatch(location)

Function arguments (2 or fewer ideally)

Less than 3 argument of your function makes your function easier to test. 3 or more argument leads to a combinatorial explosion where you have to test tons of different cases with each separate argument. Usually, if you have more than two arguments then your function is trying to do too much.

Bad

def create_menu(title, body, button_text, cancellable):
# ...

Good

class Menu:
def __init__(self, config: dict):
title = config["title"]
body = config["body"]
# ...

menu = Menu(
{
"title": "My Menu",
"body": "Something about my menu",
"button_text": "OK",
"cancellable": False
}
)

Functions should do one thing

So far, this is the most important rule in software engineering. Create a function that does only one thing/action, it can be refactored easily and will read much cleaner. What if I tried to do many things in one function? And many functions that do this thing also? Well, enjoy the “peaceful” process of testing and understanding the code!

Bad

def email_clients(clients: List[Client]):
"""Filter active clients and send them an email.
"""
for client in clients:
if client.active:
email(client)

Good

def get_active_clients(clients: List[Client]) -> List[Client]:
"""Filter active clients.
"""
return [client for client in clients if client.active]


def email_clients(clients: List[Client, ...]) -> None:
"""Send an email to a given list of clients.
"""
for client in clients:
email(client)

Function names should say what they do

It is similar to the variable, we also need to create a meaningful and pronounceable function name. Not only that, but we also need to make sure that the function is doing just like its name.

Bad

class Email:
def handle(self) -> None:
# Do something...

message = Email()
# What is this supposed to do again?
message.handle()

Good

class Email:
def send(self) -> None:
"""Send this message.
"""

message = Email()
message.send()

Whoa. So, the Conclusion?

This is the second English article that I wrote, and I’m sorry if my English is bad. This article is just like a summary and paraphrase of some more detailed sources. But for me, these are the 5 points that quite easy but really important to understand. So, instead of:

x = ('Python', 'Java', 'C', 'C++')
for i in range x:
#Blablabla do something

You can start using:

programming_language = ('Python', 'Java', 'C', 'C++')
for prog_language in programming_language:
#Blablabla do something

For me, the Clean Code concept is not about reducing the code length, but make it easier to read and understand. You can see all of the examples above, almost all of the good codes are longer than the bad code but easier to read and understand. Instead of reducing the code length, I prefer to reducing the time for testing, debugging, and understanding the code.

References

This is the detailed sources that I take to create this article. Thanks to the creator of this source before! You guys can learn more from these sources. Enjoy!

--

--