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