Hello everyone !

This week, I have been studying about clean code. Honestly, i haven’t implemented it but i’ll implement it to my next code and always implement it. Oh ya, in here i only summarised some key things and found some useful tips so, if you found something wrong, just contact me hehe.

Actually, the topic is so famous among software engineer. “And the most important book that should be read or anyone who wants to be a good software developer is Clean Code by Uncle Bob”, said mas Iqbal and mas Arief as instructor in technical class. The book is The Clean Code book, written by the God Robert C Martin, also known as ‘Uncle Bob. Ya, this book is in my reading list actually and i already have the e-book.

So, clean code is based on my what i have learn yesterday that clean code is code with right format that easily to understand if code read to another programmer and easy to change because your code will be read more often that it is written, your code are not the only user of your code and your code (most probably) are not the only one that will maintain it.

First things first, we have to know about code smell. Because, how to know the code is clean without to know the code is (in sense) dirty/bad.

Code Smell

Code smell is like code makes you confused when you trying to understand the logic of program. Code smell will be run without problem, error or bug, but makes you confuse to read and difficult to maintenance. Determining what is and is not a code smell is subjective, and varies by programming language and developer. So, there is several reason that makes your code is smell like have a duplicate code, the methods too big, classes with too much code and too many instance variables.

So, what are characteristics of clean code?

  • Elegant and efficient. Clean code does one thing well. (Bjarne, inventor of C++)
  • Reads like a well-written prose, full of crisp abstractions. (Grady, autor of OOA)
  • Can be enhanced by other developers, has tests, meaningful names, smaller is better. (Big Dave, founder of OTI)
  • Pretty much what you expected. (Ward, inventor of Wiki)

Names

  • Use name that pronounceable and searchable
  • Make meaningful distinction
  • Pick name that can give you an abstraction of the name
  • Use intention-revealing names
  • Pick one word per concept
  • Classes and objects should have noun or noun phrase names
  • Methods should have verb or verb phrase names

Comments

Add comments only to explain how you write this or don’t add comments if you can explain it in code.

Formatting

  • Vertical formatting
    • Vertical openness
    • Vertical density
    • Vertical ordering
  • Horizontal formatting
    • Horizontal alignment
    • Indentation
  • Be consistent with the rules of your team

Function

  • A function should be short/smal and only do one thing. If your function is doing more than “one thing” better to extract to another function.
  • Prefer fewer argument, a function shouldn’t have more than 3 to 5 arguments. Keep it as low as possible.
  • Have no side effects. A function should not do anything other than what its name describe.

I have one things that i think is interesting, the name is rule of three. Maybe related with Dont Repeat Yourself or DRY:

  1. When you are doing something for the first time, just get it done.
  2. When you are doing something similiar for the second time, cringe at having to repeat but do the same thing anyway.
  3. When you are doing something for the third time, start refactoring.

I think if we try to follow or implement these principles, i believe our code quality will be much better and easy to maintain.

Thank you !!!