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

There is a mistake on the part of junior -level developers that the “concept” of clean code almost translates into writing less code. In my experience, in addition to theoretical readings, a clean code is a code that follows good programming practices, standardization, which make it readable to other developers, or even to you in future maintenance.

Keep this article in your favorites to review it frequently. Continuously I will add new tips here. Follow me on my social networks where I will warn when new tips are published.

Each tip presents examples in some programming languages. Some tips can be exclusive to language characteristics. But before the tips we will 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 to your computer. Computers are machines that understand binary instructions, they don’t need beautiful code. They don’t even need their structure of sophisticated files or well-designed architecture. An interpreter or compiler translates your work into the machine’s code that doesn’t resemble your beautiful original state.

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

=> The well written code, the clean code, facilitates this process.

When focusing on people, you change your mental model when analyzing your code, you no longer question if “code works?” but asks if “Is it easy to understand?”.

The computer understands and interprets the most poorly written code in the world, as long as it contains valid instructions. It are persons who need more time to connect all points and see the facilities in the code. You can help them (and yourself in the future) by reducing cognitive load using adequate abstractions, expressive nomenclature and consistent style.

Even if you think it doesn’t apply to you, I believe you should care. If you conduct a project alone in a company, someone else can join you because of higher demands. If you quit your job, another developer will assume your work. If you go to work on another project, in the future you will need to read your own code when you return to it to maintain.

Now that you understand the value in writing clean code, let me show a non-definitive set of good practices to write it.

Return early

Perform the return of your functions and methods earlier. This means executing the return as soon as possible, when this avoids nestled structures or the use of else instruction.

I will start with a simple code, a function that calls the exclusion of an item writing in Javascript:

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

  return false;
}

There is nothing wrong with this function, but your reading forces us to go through all your lines to understand what happens if the item is equal to null. Its refactor using the Return early standard 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 returned in the first line if the main logic should not be performed.

References