The Unintentional Nature of Bad Code

I read an article on Reddit today that prompted me to share my thoughts on why poorly written code can still have value and purpose.

Unoptimized code, ugly code or whatever you choose to call it, is not inherently detrimental to applications. The main reason for this is that real-life problems cannot always be solved with straightforward algorithms.

Additionally, not every problem has stable or well-defined inputs and outputs. You might encounter situations with numerous nested if-else statements or loops.

It’s important to remember that there’s no need to be intimidated by this complexity; sometimes, using multiple if-else statements or overriding functions repeatedly is necessary. However, this doesn’t mean that optimizing code or cleaning code isn’t important.

The key point of this article is that while optimization and clean code is essential, it is not always possible. There is a saying in the cybersecurity profession: “There is no 100% secure system,” which is true. Similarly, we could say, “There is no 100% optimized and well-designed system.”

Reason

Real life is messy; everyone faces different problems, and not every problem is straightforward, like welcoming people that registered system first time.

Real-life problems require a deep understanding, and solving them involves many different variables and outputs. For example, a week ago, I was trying to create a script for my game.

Personally, I decided use the functional programming paradigm for this script, but at the end of the day, I noticed that my code contained many mutable variables and non-pure functions.

I sat in front of my computer and began to think about how to reduce mutable variables and non-pure functions as much as possible; however, it was impossible at certain points.

But why? There were many reasons for this, but the biggest obstacle was the game engine itself. The game engine used a different programming paradigm, which prevented me from implementing 100% immutable code.

Of course, there were other reasons, such as performance issues. Additionally, I had a large switch-case statement that looked quite daunting.

Yes, the code was not pretty, but that doesn’t change the fact that it worked really well. In terms of performance, I managed to improve it after making some changes, but the script still looked quite ugly.

For example, there were 25 different functions in a class, and each function took almost 15-20 different variables. However, I forced myself to reduce the function count and tried to minimize the number of variables as much as possible, but the result was still not satisfactory. After two days, the class ended up with 23 functions and 7 different variables per function, with the last function having 9 variables.

The point is that cleaning code is not always necessary if your code works efficiently and is useful. If it functions as intended, no one will check whether there are 1,000 different objects or 100 nested switch cases except other teammate’s.

However, users will scrutinize your subpar optimizations because clients demand fast and reliable services so optimization is still key point.

How to Deal with Bad Code?

To be honest, not everything needs to be pretty or well-designed because the problems themselves are not pretty or well-designed. Real-life problems are messy and ugly; how can we solve them in a beautiful way?

Make it work first; and then optimize it and clean it up as much as possible. However, don’t strive to make it the prettiest code ever—it’s not practically possible.

If you check the source code of large companies, you will notice that their code can also be messy and ugly. But it’s not their fault; the problems they face involve many variables and do not have one straightforward solution.

Optimization is key, but achieving 100% clean and optimized code is not practical. Mixing programming paradigms is not a bad thing; you can switch paradigms as long as they are useful.

Sticking to one paradigm won’t give you any advantage, and trying to create easiest readable code doesn’t provide any benefit either if it doesn’t work well at all.

Benefits of Well Written Code

Of course, there are several benefits to writing good code, which we should discuss. For example, readability supports the development process. Well-structured code allows everyone to easily update it, identify syntax errors, and implement new features. Working with readable code is significantly easier than dealing with poorly structured code.

Good code enhances adaptability, allowing developers to implement changes and new features with ease as requirements evolve. Its well-structured nature fosters better collaboration among team members, as consistent coding standards create a shared understanding of the codebase, reducing misunderstandings.

Scalability is another key benefit; well-designed systems can handle increased loads and accommodate growth without major rewrites. Additionally, good code simplifies debugging, making it easier to identify and fix issues quickly. This clarity leads to faster resolutions and improved software reliability, ultimately contributing to a more efficient and productive development process.

Conclusion

Write the code first, optimize it as much as possible, and make it cleaner whenever there is an opportunity. The summary of this article is simply this: not every piece of step is meant to be the cleanest, and not every system can be optimized.

Maybe you need to use heavy APIs—what will you do? You have two options: either get rid of this API or make a new API in a lightweight manner.

In addition, your conditional statements may depend on multiple variables, or your algorithm might require nested loops. Additionally, a complex system may necessitate the use of numerous classes and objects. These are common challenges, and we can’t always find the best solution for them.

Sometimes we can’t achieve perfection and have to sacrifice something to make it work and useful. Finally, bad code can be sometimes useful.