Anti-patterns You Should Avoid While Coding

'Anti-patterns' have been observed in numerous parts of the development process and come in different forms. The most well-known source of anti-patterns is outdated patterns, considered defective when negatively affecting the development process. Becoming outdated can happen rapidly because of outstanding development.

The term Anti-patterns first appeared in 1998 in the book AntiPatterns & C Traps and Pitfalls . Andrew Koenig, a Bell Labs programmer, wrote this letter. He says, An anti-pattern is just like a simple pattern; it gives something that looks superficially like a solution. In other words, it looks like a solution but eventually turns out the opposite, doing more harmful effects than good.

Anti-patterns may harm your software. They either raise more bugs and security issues or hinder code readability and maintenance. One of the most incredible ways to identify an anti-pattern before it has a significant effect is to search for explicit code patterns called code smells. These smells can show a more substantial issue with the source code yet require more examination to assist you with sorting out the root of the cause.

Below are the top 10 anti-patterns that you should avoid while coding.

• Spaghetti Code
• The Golden Hammer
• Reinventing The Wheel
• Hard Coding
• Dependency Hell
• God Class or Object
• Lava Flow
• Cargo – Cult Programming
• Boat Anchor
• Copy – Paste Programming

Anti-Pattern: 1 - Spaghetti Code

Spaghetti Code

You may observe how each spaghetti is tangled & jumbled with the other. You can't even see the start or the end of all spaghetti. It is not surprising to see similar code in the software development process.It's called Spaghetti Code . It is one of the most famous code anti-patterns, and most apps today are survivors of it. It fundamentally emerges when a developer begins dealing with an undertaking before observing the program flow and understanding the documentation well.

This kind of code winds up muddled. It needs legitimate restrictive blocks, various GoTo statements , strings, and exceptions . It has code snippets that have a place with different spots, capabilities that conjure numerous capabilities from other parts, and techniques or classes that the program can't reuse.

Things become more terrible as your program develops. Your generally untidy code becomes messier. You begin having various capabilities in various documents conjuring one another. You start copying and pasting previously working code to take care of an issue in a different part of your application .

A big part of the application breaks whenever you erase a solitary function. This kind of code is difficult to scale, expand and keep up with. Furthermore, when another developer assumes control, they should invest a lot of time fixing and enhancing the current code before dealing with new undertakings.

Anti-Pattern: 2 - The Golden Hammer

This anti-pattern is a well-known solution in software development and is ordinarily used to make the development process much quicker. It alludes to the idea of utilizing a solution to tackle issue A to solve problem B.

For better understanding, let's imagine you are developing an application and encountering several issues. You create a solution that helps you tackle problems A and B. When you encounter a problem C, you use the same solution because it worked for the others issues.

You use this solution as the Golden Hammer for all your issues. But that is not a decent practice, and you might end up with an excessively complicated code by attempting to fit the solution where it's simply unimaginable. In software development, every issue has a unique solution.

Always pick the right tools, libraries, frameworks , and architecture for every problem. It's continuously prescribed to come up with at least two explanations for each issue. Gauge the upside and downside before implementing one that you find appropriate.

Anti-Pattern: 3 - Reinventing The Wheel

It is another anti-pattern you will encounter frequently prompts too much time on a project. It alludes to a scenario where developers opt to develop a custom solution instead of existing solutions in the market with the assistance of API & libraries. This anti-pattern primarily emerges when developers think the ongoing problem is unique to solve with the current solution and poor communication between development groups.

Consider an organization that needs to add a blog/posts page. It will require time and assets if developers foster a custom Content Management System (CMS) without preparation. They can decide on arrangements like WordPress, Joomla , and headless CMS like Strapi, Ghost, or Contentful . Making a custom arrangement is not so great when a current and working arrangement is known as Reinventing The Wheel.

Anti-Pattern: 4 - Hard Coding

This anti-pattern is most common in web development . A developer directly adds different parameters into the source code instead of fetching them from a database, API, user input, the '.env' file, etc. Two main concerns emerge with this anti-pattern are:

• Security: If you hardcode a verification parameter such as an API access token or JWT token, somebody can undoubtedly access it by surveying the source code from the browser.

• Environmental Change: When you hardcode parameters in development, your app will work amazingly. However, the application breaks when you push the changes to the production environment. You will need to edit the source code every time to suit every environment.

Anti-Pattern: 5 - Dependency Hell

The application's general performance, maintenance, and scalability highly depend on the code structure. The complex nature of the software development process keeps developers working on an application; this might resolve to use as a quick solution to an anti-patterns problem.

When you center much around staying away from Wasting time , you will probably fall into dependency hell. Rather than developers creating custom arrangements, they import some outsider libraries into their tasks. Tragically, a portion of these libraries likewise depends on other outer libraries.

Consequently, to import a library to assist you with executing an image carousel or get framework logs, you, in the end, bring to a circumstance where you have libraries with numerous sub-conditions. That makes the code very difficult to oversee and keep up with.

To avoid such anti-patterns, use package managers that update and keep up with every package and its dependencies smartly.

Anti-Pattern: 6 - God Class or Object

This issue emerges when developers disregard making extra classes during the project's underlying stage and want to do that later. User's/Clients first name, location, employee id, salary, number of vacations, etc. That's the typical God object.

It has too many responsibilities and dependencies. Tragically, they keep adding more liabilities to the initial class that significantly different capabilities and techniques rely exclusively upon. By and large, it is seen as the application's primary class.

For better understanding, let's see an example of a Javascript object that acts as a 'God Class.'

const schoolObject = {
  studentID:"",
  studentCourse:"",
  studentClass:"",
  teacherID:"",
  teacherSalary:"",
  staffID:"",
  staffSalary:""
}

Note: The schoolObject above has many responsibilities. It can be subdivided as follows.

const studentObject{
  studentID:"",
  studentCourse:"",
  studentClass:"",
}

const teacherbject = {
  teacherID:"",
  teacherSalary:"",
}

const staffObject = {
  staffID:"",
  staffSalary:""
}

This anti-pattern goes against the Principle of Single Responsibility in programming. According to this principle, each class should have a single responsibility or purpose in your project.

Anti-Pattern: 7 -Lava Flow

This anti-pattern refers to the idea that developers have to manage repetitive or low-quality code; however, it seems to play a part in the general working of the application. Eliminating or editing this code is risky since individuals are unaware of what will happen to the application. Many issues emerge from heritage code during the task's initial stage.

Perhaps the developers needed to follow the documentation, the project was moving too fast, and they needed more opportunity and time to enhance and refactor the code. Alternatively, maybe the project began as simple & basic research, and nobody took the development phase profoundly. When it eventually becomes a product/item, you find numerous redundant code pieces whose function and purpose are unknown to all.

Furthermore, it turns out to be furious if the developer is unavailable in the organization or they need help remembering something regarding the code. This anti-pattern derives its name from a volcano that behaves like how the Lava comes out from a volcano behaves. Initially, we know the Lava is hot and in liquid form and quickly flows down the mountain, and later on, after cooling, you cant remove it.

The best solution to prevent lava flows is extensive testing and refactoring. Developers invest a lot of time attempting to grasp the code and might leave it for fear of breaking the application.

Anti-Pattern: 8 -Cargo – Cult Programming

This anti-pattern gets its name from a story. After WWII, tribal societies from the south came into contact with the western civilization. This was the first time for the natives to see such kinds of products as radios, Coca-Cola, etc.

Since they had never seen such things as' cargo' and didn't understand the manufacturing process, they started imitating the western culture, hoping the gods would send cargo to the island. This approach led to the rise of the cargo cults name.

Cargo-cult programming alludes to using libraries and frameworks that work well without knowing why you need them in your project & how they work behind the scenes.

Anti-Pattern: 9 - Boat Anchor

This anti-pattern usually emerges when developers code an app with the what if possibility question in mind. What if we need to add new features in the future? What if this particular scenario occurs in any of my codes? Because of these questions, developers write additional lines of code not needed by the app at that specific moment.

According to them , these extra lines may or may not be helpful. But, this anti-pattern does more harm.

In the future, when developers look at/check your code, they can see a few techniques and classes that are uncertain of their purpose in the application. They invest much time understanding and debugging the code instead of focusing on other tasks. This unnecessary code becomes like a boat anchor . It does anything at that moment, yet your app still needs to convey it because you think you might require that code in the future.

Anti-Pattern: 10 - Copy–Paste Programming

This anti-pattern mainly occurs when reviewing the code of an inexperienced developer. Since they may need to be better familiar with the best solutions for complex issues, most copy and paste code snippets from stack overflow, GitHub, blogs , and youtube videos. Tragically, most developers need to dissect the effect of this copy- pasted code.

The main thing that matters is that it works! Using these code snippets in different project sections leads to highly repetitive code, which goes against the DRY programming principle. This anti-pattern is not only limited to junior developers. Seniors developers are a victim too. Most opt to copy-paste their already working and well-tested code for specific tasks. Unfortunately, that eventually leads to unintended repetitions in the code.

Conclusion

Software development is a field where we constantly look for patterns, but ignoring anti-patterns can be worse than choosing less optimal design patterns. Don't panic or feel bad because some of the anti-patterns discussed above may be available in your code. That is a phase that every developer goes through before they become better.

If developers can identify these issues early on, it can save time and reduce refactoring in the long run. But recognizing an anti-pattern during development can be tricky since other issues with the development process can distract developers from recognizing the signs. Take that as a learning curve to learn and develop. You can quickly solve these anti-patterns using standard solutions.

I hope this guide will help you know the anti-patterns you should avoid while coding. Any queries, suggestions, or comments? Drop them in the comment section.

Thanks!!!

Tags