In addition to learning about design patterns that should be referenced when programming, I wanted to learn about bad software design, which led me to anti-patterns.
A wonderful source covering anti-patterns that I learned from can be found at: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/.
Anti-patterns are bad software designs that show how not to solve problems in programming. The source covers 6 different anti-patterns: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object.
Spaghetti Code is when there is barely any structure to the code. Files are thrown in random directories and it is difficult to follow the flow of the program. This would produce many issues when needing to modify the code, because the program can break and it would be difficult to tell what caused it. It would also be difficult to estimate what may break after you make a change.
Golden Hammer is when you repeatedly use an architectural approach in your code that does not exactly fit the program you are making. Despite the fact that it doesn’t exactly fit the program, it is still utilized because it gets the job done eventually. Problems arise from the fact that it does not fit the program, and can cause longer runtimes.
Boat Anchor is when programmers leave code in the codebase that has no purpose at the moment, and is kept incase it is needed in the future. This code acts as an anchor because it holds the program back– it increases build time, and can make code reading difficult when programmers have to discern between code used and the code saved for later.
Dead Code is when programmers cannot tell which parts of code are currently necessary for the program and which parts of code are no longer needed.
Proliferation of Code is when objects in your codebase only serve to create a more important object. This makes the code more difficult to follow.
God Objects are objects that have too many responsibilities. The code should be broken down more so that objects do not have to undergo functions that other, smaller bits of code can cover.
The Boat Anchor anti-pattern reminded me of YAGNI (“You aren’t gonna need it”). YAGNI is the principle that you should not add functionality to the program until it is actually needed. Adding the functionality in advance may end up messing with schedules and requirements may be changed in the future where that functionality is not even needed. The God Object anti-pattern reminded me of the single-responsibility principle (which the article briefly mentions). These anti-patterns will be very useful to apply to my code to prevent the program from being too complex and hard to follow.
From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.