Clean Coding

Danin Sudjono
PDB+R
Published in
3 min readApr 17, 2019

Hello, lovely readers of our medium. It’s Danin again, and today I want to talk about clean code.

What is Clean Code?

There is actually no clear definition of what clean code is, but here are a few quotes that define what clean code is:

“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.” — Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control” — Grady Booch, author of Object Oriented Analysis and Design with Applications

“You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.” — Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming.

Summarizing the quotes above, clean code is an effort of making simple, easy to understand, but also effective code.

How do we Clean Code?

To answer this question, ask yourself: How do you clean your room?

In practice, cleaning a room and cleaning code is very different. But the fundamentals stay the same. We clean our room so everything is organized, so it doesn’t smell, and so whoever uses the room will feel comfortable. Well, we clean our code so everything is organized, so it doesn’t smell (code smells is a thing), and so whoever uses the code, user or developer, will feel comfortable.

Here are a few things you can do to implement clean code:

1. Meaningful Names

You want your variables to explain what they do. Picture this scenario: You have a program that counts the total price of a list of items. The total is stored in a variable simply named total. Now this is fine, but let’s say your program also has a counter for the total number of purchases done. Now, the variable name total is ambiguous. By renaming the variable to let’s say, total_price, we clarify the meaning of the variable and reduce ambiguity.

2. Quality Comments

Comments should not explain code; Code should be self-explanatory. What comments should be used for is to explain intent, clarification of problematic points, consequences or warnings, and TODO comments among others.

3. Concise Functions

Create simple functions with a clear purpose. Instead of having a lot of the same code, we can keep it all in a function. Don’t make the function too long, and make sure it’s easily understandable for other people to reuse.

4. Elegant Error Handling

You want to write the try-catch statement beforehand in case of errors showing up. You also want to define the normal flow, and only put exceptions where they are most likely to show up. Use unchecked exceptions to prevent runtime errors.

5. Code Formatting

Code formatting means consistent spaces and tabs, whitespaces, and very minor details that you normally won’t notice when coding normally. These can be searched out using linters like pylint and flake8, and while not necessary, helps with the overall quality of the code.

…and many more!

I can talk about how to clean your code all day, but sadly I don’t have all day. The whole point of clean code in an agile environment is so that each developer has a standard to work with. You can’t just give your spaghetti code with errors to another developer hoping they can fix it. Cl

That’s it for now. See you next time!

--

--