I dare to say that most problems in software development are caused by the next top 5 bad coding practices. This really happens despite software developers do the right things most of the time, but sometimes the newbies or even those with some experience are not aware of this. As a programmer I did some of this at the beginning in my career, I confess it, and probably I am doing others don’t listed here, so the intention of this post is you know them and also you avoid them at all, but you and I know that bad habits are hard to break them out and harder if we don’t realize of it.
I have seen a lot of poor coding practices, and probably the developer who is working on one of my first one jobs is realizing the same thing I am saying, I just can say, I am sorry, I had to survive at that moment. Now, I realize that I could have done a better code if I would have known these bad practices and got them away, the applications now could be more scalable and maintainable and of course, the work easier for the current developer.
As you know the rule known as the 80–20% or Pareto Principle says that 80% of outcomes can be attributed to 20% of the possible causes of a given event, similar apply for coding, the 80% of problems come from of the 20% of bad coding practices.

Just to keep in mind, all of these bad practices have been gathered based on my hands-on and also by wide-list experts in this industry, developers around the world, so let’s get started!.

1-Not commenting your code/documentation

Probably most of us are going to say, come on, this does not matter, but let me tell you, it matters!. No matter how smart you are, it’s true that sometimes we work in some easy code parts, where the code is explicit itself, but what happens on the other side, when the code has really complex parts, so it is more likely that you will forget what your code does or even why your code was written using certain algorithm or a specific approach . So, it is the truth, that sometimes we need to finish the project as fast as soon as possible, but write 2 or 3 lines of a descriptive comment is not going to take a life, it is very important and useful to comment classes, methods…etc. In the future that will help you and others as well. Thus, I would comment the code properly. But their code that does not need comments because is obvious, it is really not productive to repeat it.

2-Violation of the Single Responsibility Principle (SRP)

Sometimes as a developer we write methods or classes which might include not just one responsibility and also more than one reason to change. This really bad. Why? You will have to handle all the maintenance nightmares it will have. As we all know there are some cases which are tricky and require care to figure them out, so it is likely on those case we are not going to prevent to fall in this violation principle, in a future post we are going to discuss where and how we can put attention to it.
A class should have only one reason to change. We must write functions or classes that should do one task and one thing only so to achieve this, we have to keep related data and behavior in one place, this is essential to building consistent abstractions, it means to avoid disclosure unnecessary details, duplicate or have inconsistent behavior and uncontrolled growth.

3-Spaghetti Code

Spaghetti code sometimes is the result of older code being modified many times over the years. If you have worked on projects maintaining them, you actually know what I am talking about, it will sound so familiar. On those project might be so difficult to avoid spaghetti code, but in other projects, you should avoid this kind of code because has a complex and tangled control structure, it is difficult and unreadable to others even for yourself after a while when you come to get back to it. We also know that the causes of this are several such as changing project requirements, lack of programming style rules or standards or lack of experience.
To avoid the above we need to analyze the problem and divide it into chunks smaller (components, modules) to understand it, on the other hands we should use modular coding, think in terms of re-usability, separate the parts based on a specific purpose, testing, naming conventions, etc.

4-Hard Coding and Magic Numbers

We need to avoid the uses of hard code in our apps, please get it away of embedding data directly into the source code. We need to find a better way to do the app more generic and customized. Instead of using hard code string or in general we should be use files or tables for retrieving data, one place to modify them once time.
Another bad coding bad practice we need to avoid is the magic numbers. What does heck a magic number?. It’s in other words whatever constant, completely undocumented without a reason why its value is so important for our program. Most of the time nobody knows why those values were chosen neither documentation for it, so since it is magical no one knows the real effect and how it's going to impact other parts of the program.

5- Convincing yourself that styling issues are not that important

Our code is much better if we use a style consistent. It does not matter what type o style, the most important thing is using one of them. In my coding journey through the years I have learned that maybe this is one of the thing most of the developers more likely to put it off.
Remember, the order is a synonym of peace and really it is pleasant to see it. A good property structured code is going to gives more productivity to whoever is trying to figure it out, understand it, identifying where a block of code starts and ends, as a result of that you can follow the logic easier.
Thanks for reading! If this story turned you out interesting, I’d really appreciate it if you like and share it with your friends. I hope to add a little bit more knowledge to you.
Supporting and follow me on my blog and Medium