Write Better Code by Knowing What’s Bad
5 qualities of bad code and why you end up writing them anyway
Cover Photo by iMattSmart on Unsplash
Let’s admit it: We all want to write good code. You will feel way better working with code written with good standards rather than handling code that is a mess. Good code might need a little more effort initially, but it will help you a lot later on.
You might be wondering why “qualities of bad code” were mentioned above. In order for us to understand why something is good, we need to understand why something is bad. This will help us to value the good part more.
Although the concept of good code vs bad code is subjective, we can agree on some qualities of bad code that are very obvious. Let's see some of these qualities of bad code.
1. Code Duplication
When many programmers work on different areas of the same software at the same time, duplication can arise. They may be unaware that their teammate has created code that can be reused since they are engaged in separate tasks.
Duplication can sometimes happen because of the programmer being lazy. They might be simply too lazy to declutter.
Some types of code duplication can be harder to detect. Functions that look different but give the same output can be hard to find and fix.
Although it is unavoidable to duplicate code at times, we must ensure we keep this to a minimum.
2. Spaghetti Code
Every developer has written spaghetti code at least once in their career — and they would know how much of a pain it was later on.
Spaghetti code is basically like spaghetti. It is twisted and tangled and hard to manage. It has pieces all over the place, which makes it even difficult to debug.
To avoid spaghetti code, make sure your functions perform only one action, and your classes are responsible for only one purpose. The single responsibility principle in SOLID mentions this.
function addAndMultiply(number1, number2) {
//Code to add two numbers and multiply them
}
If you see the function above, it performs two tasks. Although this function looks simple, it can become troublesome when your function and code grow in size. That is why it is always a good idea to give a single responsibility to your functions and classes.
Photo by 3. Contains Copy-Pasted Code
According to The Coding Delight, there are two reasons why people copy-paste their code:
“- It is a quick way to get something working properly (e.g. code snippets from StackOverflow).
- To import and use a feature that you require, but don’t know how to build on your own.”
Using something from the internet is not always bad. But you should know what you’re doing. One common thing with copy-pasted code is that the developer has no idea how it works. Although it might not concern you, it is something you should be concerned about. There have been several security concerns with code taken from platforms like Stack Overflow. You can read more about these and why they can break your project in this article.
4. Poor Naming Conventions
Although it is purely subjective whether you should use camel case or pascal case, there are some things that are agreed upon to be poor naming conventions.
I strongly believe that good code does not need any excessive documentation. The code should be able to speak for itself. The functions, variables, and classes should be named in such a way that they are self-explanatory.
Since programmers are team players, you should always keep in mind that your code should serve to accurately inform the next developer about how a particular problem was solved.
5. Contains God’s Code
I call this “God’s code” because only God would be able to understand these types of code since the developers themselves would forget what it does and how it works overtime.
Some people are obsessed with finding a shorter alternative to their code and end up with a two-liner that performs the job of ten lines of code. Although this is good, it should not come at the cost of readability. These types of code end up having very poor readability. At the end of the day, you would have traded readability for shortening your code.
As Christian Maioli wrote for codementor, “Make your code accessible first, then clever.”
Why Would You Write Bad Code?
People who write bad code are not dumb. They just have a few habits that make them do it. The good thing about this is you can simply unlearn these habits and grow towards success. Let’s see why people write bad code.
You don’t have enough experience and knowledge
This is kind of an obvious reason why people write bad code. Everyone has written bad code at least once in their life as a developer. Writing good code happens with time, experience, and knowledge.
Keep learning, and you will eventually get there with time. Start reading books written by great developers. I would personally recommend Clean Code by Robert Martin and The Pragmatic Programmer by Andy Hunt and Dave Thomas.
You do not ask others for help
Most developers are introverts, but that does not mean that they cannot talk and interact with others. It’s just that they are shy initially.
Although this is totally fine when you are coding alone or trying to solve problems on your own, this will put you at a standstill when you get stuck on a problem or are working on a team.
A lot of people think that asking for help is only possible with online platforms like Stack Overflow. In reality, you should be able to talk with your supervisor or teammate and discuss your issues with them. They would be able to provide you with a better solution with their expertise than what you would find on online forums.
People skills are very important for teams to function smoothly. By being able to get help from your peers, it will help you develop a smooth relationship with them.
You have lower expectations
If you aim lower, you will reach lower. Set high standards for yourself. You will achieve them. A lot of beginners believe that it is acceptable for beginner programmers to write poor code.
Although this is true, it does not mean that you can stay at that level of quality. By setting high targets and high expectations, you will break the barrier and grow to become a great developer.
You focus on the wrong metrics
“When a measure becomes a target, it ceases to be a good measure.” — Goodhart’s law
Quite a number of people believe that their performance is measured by the number of issues closed or the number of commits per day. When you start working towards targets like this, you start prioritizing speed over quality. This results in you not being able to spend that extra minute refactoring your code, as you prefer to be quick with your coding.
As Maioli wrote:
“Ultimately what matters is what is delivered to the client, how happy they are with the product, and how it affects their bottom line, but it takes a lot of self-control to focus on the delivered quality and ignore juicy metrics such as commit rate or issues closed.”
You are lazy
This is one of the most obvious reasons on this list. You can be an awesome programmer, but if you are lazy, you will not take that extra step to make sure you write good code.
You can be lazy for many different reasons. If you are lazy because of inactivity, then you better take up a sport or hit the gym with active participation. Once you feel energized, you can run your whole week with a lot of enthusiasm.
Some people are lazy because they tend to question why they should take that extra step to write good code, for them to understand why they should look at this problem of bad code from a wider perspective. Look at it from the view of a developer who would take up your position once you leave the company. If you write poor code, only you will be able to work with it. As I said before, software development is a team game, and you have to play it as a team in order to emerge victorious.
Conclusion
This article does not cover every aspect of coding practices. I do advise you to read Clean Code and The Pragmatic Programmer.
No one is perfect, but we should always strive for perfection.
If you have any additions to be mentioned in the above, please do comment below.
Thank you for reading, and happy coding!