Anti-Patterns and Worst Practices – You’re Doing it Wrong!
When shown ideal code, I think developers understand why it is favorable. When it is regarding Separation of Concerns (SoC) or Single Responsibility Principle (SRP) the consensus is something along the lines of “of course, that makes sense”. But not always do these same developers actually practice the techniques or principles. It’s always nice to see good code, but I think it’s also important to look at bad code from time-to-time.
Just as there are best practices, there are also worst practices. When you see some of these worst practices, you should do your best to acknowledge them, avoid them and try to remove them from your code, even if you have to do it little by little. The side effects of these are probably going to cause you a lot of frustration and pain in the future if they stick around for too long.
Here’s the four I’ve decided I’m going to single out over the next week:
Part 1 : The Arrowhead Anti-Pattern
This anti-pattern is quite simple. You’ll see an “arrowhead” form when your code has conditionals and loops nested within each other, over and over. The reason that this is bad is because it increases the cyclomatic complexity of the code. The higher the cyclomatic complexity, the more it is prone to bugs and defects, thus the harder it is to ensure the code works as expected.
Part 2 : Monster Objects
Sometimes referred to as God objects, these are objects that are just too big, bulky and hard to manage. If you’re familiar with ASP.NET, you’ll be familiar with HttpContext, a Monster object.
Part 3 : Heisenbugs
A Heisenbug is named after Heisenberg’s Uncertainty Principle. Which states that the state of an object cannot be accurately measured, because any attempt to do so will change the result. In software, this can manifest itself when breaking the Command-Query Separation design guideline.
Part 4 : Utils Class
In the software world, you’re probably going to come across a class with this name at some point. What does it do? Nobody knows, that’s why it exists. When you see a Utils (or Utility) class, its existence is probably due to laziness or lack of domain knowledge.