Skip to content
Start » Programming Techniques » Best Practices for Writing Clean Code

Best Practices for Writing Clean Code

In this article I present tips for when developing software, writing with good clean code practices, which, in general, means writing more readable blocks of code, in some contexts, more fluid and well structured.

There is a mistake on the part of junior developers, that the "concept" of clean code (from the English Clean Code), almost translates to writing less code. In my experience, in addition to theoretical readings, clean code is code that follows good programming practices, standardizations, that make it readable for other developers, or even for yourself in future maintenance.

Bookmark this article to revisit it often. I will continually add new tips here. Follow me on my social networks where I'll let you know when new tips are published.

Each tip features examples in some programming languages. Some hints may be unique to features of the language itself. But before the tips let's understand why write clean code.

Why write clean code?

The answer may not be obvious, you should write clean code because you don't produce it for the computer. Computers are machines understand binary instructions, they don't need pretty code. They don't even need your fancy file structure or well-designed architecture. An interpreter or compiler translates your work into machine code that looks nothing like its original beautiful writing state.

So why should you be concerned? Because you write for people, not machines. Machines can run the program with extreme speed, while people need time to read the code line by line and interpret what it does, projecting what the result will be.

=> Well-written code, clean code, makes this process easier.

By focusing on people, you change your mental model by analyzing your code, you no longer question whether “It works?” and goes on to ask "It's easy to understand?”.

The computer understands and interprets the most poorly written code in the world, as long as it contains valid instructions. It's the people who need the most time to connect all the dots and see the dependencies in the code. You can help them (and yourself in the future) by reducing the cognitive load using proper abstractions, expressive nomenclature, and consistent style.

Even if you don't think this applies to you, I believe you should care. If you lead a project alone in a company, someone else may join you because of higher demands. If you leave your job, another developer will take over your job. If you are going to work on another project, in the future you will need to read your own code when you come back to it for maintenance.

Now that you understand the value of writing clean code, let me show you a non-definitive set of best practices for writing it.

return early

Return your functions and methods sooner. From English return early, means to run the return as soon as possible, when this avoids nested structures or the use of else.

I'll start with a simple code, a function that calls the deletion of an item:

function deleteItem(item) { if (item != null) { console.log("Deleting item"); item.delete(); return true } return false; }

There's nothing wrong with this function, but its reading forces us to go through all its lines to understand what happens in case the item is equal to null. Your refactoring using the pattern return early would result in the following code:

function deleteItem(item) {
  if (item == null) return false

  console.log("Deleting item");
  item.delete();
  return true;
}

In the first example, in addition to using a comparison with negation, making it difficult to read, we need to map the code block that contains the main logic of the function.

In the second example, we simplify the reading of the comparison, testing an equality, and we return it on the first line if the main logic should not be executed.

References

Leave a Reply

Your email address will not be published.

en_USEnglish
%d bloggers like this: