I dare to say that most problems in the software development are caused by the next top 5 bad coding practices. This really happens despite to 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 maybe 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 in one of my first one job is realizing the same thing I am saying, I just can say, I am sorry, I had to 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 collected based on my dev experience and also for a wide 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 no matter, but let me tell you, it matter!. 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 complex parts, so it is likely that you will forget what your code does or even why your code was written using certain algorithm or approach . So it is truth that sometimes , we need to finish the project 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 there code that do not need comments because is obvious, it is really not productive to repeat it.
2-Violation of the Single Responsibility Principle (SRP)
Photo by stackify.com
Sometimes as a developers we write methods or classes which might be include not just one responsibility and more than one reason to change, so I can assure you that you will have to handle with all maintenance nightmares it will have. As we all know there are some cases which are tricky and require careful 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 be have only one reason to change. We must to 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 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. You should be 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 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 analyse 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 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 word 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 a documentation for it, so since it is magical no one knows the real effect and how is 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 use one of them. In my coding journey through the years I have learned that maybe this is one of the thing most of developers more likely to put it off.
Remember, order is sinonim of peace and really it is pleasant to see it. A good property structured code is going to gives more productivity to whom 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 it 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 of knowledge to you. Don’t forget to follow me on Linkedin too.
