How to gain agility and productivity by writing clean code

Have you ever found yourself in a situation where you are doing a task, and at some point, you must 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 that you spend more time trying to understand the code than doing the task. I will introduce you to Clean Code to solve these and other problems!

 

What is clean code?

 

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

 

Why write clean code?

 

Some people have already felt 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 technique that takes many actions is not clean. It should be focused on a goal only and should run most efficiently.

 

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 words. The idea is that the character meets precisely what the code does. It must be significant. A comment 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 idea 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 take a few weeks’ breaks. When you return to the legend, if you understand exactly what it is written without much effort, it is because you have achieved your goal!

 

ProTip

 

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

 

I often find it easier to understand the tests than the code itself. Some tests are better written because of the pattern that encourages people to describe exactly what the test does with more precise, 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 have much more excellent readability. 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 putting these ideas into practice initially, but upfront, you win in time and simplicity.

 

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