Have you ever found yourself in a situation where you are doing a task, and at some point, you have to tinker with someone else’s code? I bet a lot of people have been through this. Even so, you do not give up understanding the code. However, there is so much confusion and clutter in there that you end up spending more time trying to understand the code than doing the task. To solve these and other types of problems, I will introduce you to Clean Code!

What is clean code?

We can say that the clean code is that elegant and well-written code that, when we pass the eye, we can quickly understand what it means. When reading a clean code, your reading should be smooth like reading a good book. In other words, it’s a beautiful code, wonderful, direct, simple, and focused on the goal. It’s that code you’re proud to show to other people.

Why write clean code?

I think some people have already felt in their skin what it’s like to be hindered and unproductive because of messy codes. Writing clean code helps you organize your code in several ways to prevent this kind of thing from happening to you and your co-workers.

One of the most important reasons is the agility of reading a clean code. A clean code is much easier to read and does not require much effort from the reader. There is no need to read three or four times. One handles and you are ready to continue the task.

In addition to helping the person who needs to understand your code, you end up helping yourself as well. If you take those deserved vacations, when you return to work on your project you will separate the time to understand where you left off and what you were doing. If you write clean code this time will not be extensive. And as Robert C. Martin once said: – “The only way to go fast is to keep your code clean.”

How to write clean code?

Now you ask me, “How do I write it in a wonderful way that will only bring me benefits?”

  • Here you have the freedom to be short and thick. Write small code in the simplest way possible, without many robust and complex words, but with words that define more fully what the method does or what that variable represents.
#bad code ;(
def getPayAmount()
  if is_dead? == true
  else
    if is_separated? == true
    else
      if is_retired? == true
      else
        normalPayAmount
      end
    end
  end
end
#good code <3
def getPayAmount()
  return 0 if is_dead?
  return 0 if is_separated?
  return 0 if is_retired?
  normalPayAmount
end
  • Methods should have only one purpose. A method that takes many actions is not a clean method. It should be focused on a goal only and should run it in the most efficient way.
def discount
    price * discount_percentage
end
  • Give descriptive names. Try to be as direct as possible when choosing a name, without much coaxing, without a much hard word. The idea is that the name meets exactly what the code does. It must be significant. A word is sometimes enough, or in the case of a method, a verb is enough. If you cannot find a word that can be very descriptive we can use phrases. But the ideal is to find a middle ground between a too broad definition and a too big name.
def calculate_salary employee
    return employee.salary * 0.8 if employee.salary > 3000
    return employee.salary * 0.9
end
  • Do unit testing. In addition to being self-explanatory, writing the tests helps you better think about the role of your code, how the method will work, and what it will take to make it work.
describe '#name' do
  context 'when is a default name' do
    context 'and locale is english' do
      ...
      it { expect(segmentation.name).to q I18n.t('segmentation_lists.default.opportunities', locale: :'en') }
    end
  end
end

The best way to know if you write clean code is when you write the code and takes a few weeks break. When you return to the code, if you understand exactly what it is written without much effort it is because you have achieved your goal!

ProTip

It is very important to define meaningful names that describe what the code does. That’s where we gain the agility to understand the code and increase in productivity. We can focus our efforts on achieving our goals and not waste time trying to understand what the code does.

I often find it easier to understand the tests than the code itself. Some tests end up being better written because of the pattern used that encourages people to describe exactly what the test does with clearer, more objective words. When the test has descriptive blocks like describe, context, and it – which serve as a title, subtitle, and description of the code – I end up having a much greater readability of the code and I can better understand all the context involved in that block.

So, if you’re stuck in another’s code, take this tip into account:

(I.e.

It is always good to validate these factors when it is time to put your hand in the dough. You may even have difficulty at the beginning to put these ideas into practice but, up front, you end up winning in time and simplicity.

Do you have any Clean Code tips? Share with us in the comments!