Ifception

You know that smell.

We all do.

It’s a smell of a new.

New car. New furniture. New project.

It’s an excitement to work on a brand new project.

Everything goes smoothly. You are finishing one feature after another very quickly. But, after a while, this started to change. The features take longer to finish and the first bugs occur in your code.

What’s going on?

The reason for this could be that the code is becoming messier the longer you are working on it.

You will know this is true if some of the following are true:

  • Methods are too long and have too many parameters
  • There is duplicated code all over the place
  • Names of your fields, methods, and properties do not represent what they do
  • You have classes that do too many things. How to recognize them? Check the number of lines in the code. Or, if a class has “Helper”, “Manager” or “Utils” in its name, then there is a high chance that the class has too many responsibilities.
  • There is a lot of nested if logic. If inside an if, inside an if statement.

I call this Ifception.

But, there is more.

The clients require the changes all the time, so having to go to the codebase and change something can be a huge pain.

Does it have to be like that?

No, and let me explain. If you do all of this:

  • Names of your fields, methods, and properties clearly express what they mean
  • Methods are short and have few parameters
  • Duplicated code is extracted into separate methods
  • The classes have few responsibilities
  • There are no nested if statements

Then it will be easier to have a clean, maintainable code.

A code that will smell as fresh much longer. A code that will be easier to change. A code that will have fewer bugs.

Here’s to a better code.