Programming isn’t always as simple as it seems; sometimes it requires you to write code that might not be quite as straightforward or easy to use as you’d like. You might also need to edit other people’s messy code from time to time if you work in a company where developers aren’t the cleanest coders around, and that can prove to be rather problematic and annoying, especially if you don’t know how to do it properly yourself.
Limiting function arguments
It is very important to limit the number of parameters that a function has. Remember: The simpler, the better. The problem comes when a function has more than 3 arguments, because it can cause many problems in understanding what it does.
The best option is to use 1 or 2 arguments. Can you use more? Of course you can, but only if you are aware that in a couple of months you will have to figure out what is supposed to do what. The ideal would be to group when there are 3 or more.
If you have more than 2 arguments in your function, it means that function is doing too many things.
Name the functions with what they do
Another bad practice is to name functions with incorrect or incomplete names. Just by reading the name of the function we should know almost 100% of what EXACTLY it does, otherwise this only causes confusion.
The best recommendation is to spend a little more time thinking of a name that is very descriptive for the function. If you don’t do this good practice — just to save a couple of seconds in defining a good name, you will waste a lot more time in the future reading those lines of code and trying to understand what they do.
Never save unused code
This bad practice reminds me of when we keep or collect “stuff” at home but never make use of it. This is the same, if you have code that is not used, delete it. There is no point in having it taking up space and bothering you.
Remember: Don’t bite off more than you can chew. If you haven’t used that code, there’s no point in keeping it there. You can still check it again in the version history in case you ever need it.
One level of abstraction per function
If you are developing and you find that a function does not have only one level of abstraction, but has several, this means that the function is doing too many things by itself.
This bad practice, apart from in the future generating questions like: What is this? What exactly does it do? It makes it difficult to reuse code because it does many things at the same time.
This, apart from leaving the code cleaner, will allow you to reuse code and test it (which you could not do properly before due to the large amount of things the function does).
Never write in global functions
This bad practice consists of “contaminating” the globals. This is not a good thing because you could have problems and even crash with another library. Any user could run into this problem and would not realize it until the exception occurred.
After this, we load the configuration and when it is ready, we create an instance of the
Now yes, in the application, we should use one instance of