Software Design Patterns are recognized patterns that represent best practices in solving a given problem. It follows that Anti-Patterns are the opposite in that they are patterns in software coding that represent worst practices. I would even make the further distinction that Anti-patterns are not just bad patterns but more precisely the worst. To be absolutely fair, I could quite easily argue that as far as “design” is concerned, Anti-Patterns are most often derived by the lack of it. Why “Design Anti-Pattern” and not “Anti-Design Pattern”? The antonym of “design” is to “disorganize”. I doubt that developers set out to disorganize their code; therefore “Anti” is on “Pattern” not “Design”.
You may ask: Why should we study the worst patterns? The answer is much the same as why we study both the good and bad historical events in History class – we study the worst so that we may learn to avoid repeating past mistakes. So, it is just as important to study an Anti-pattern as it is to study a Pattern.
I would like to introduce the first Anti-pattern; the Power Code pattern. This was first coined by a colleague of mine who is a software consultant in Germany. The Power Code pattern falls in the redundancy class of anti-patterns. Power code is code that is repeated for no explicable reason other than to be annoying and repetitive. The reasoning for the name is quite simple: If you use the same statement enough times the computer has better retention and therefore the value gains more power. The following code is an example of a Super-Nova of power code, real life power code does not usually exist to this extreme, but it does drive home the point:
Somefunction() {
X = 3;
dosomething();
X = 3;
if (true) {
x = 3;
}
else {
x = 3;
}
X = 3;
}
From the above example we get it “x must equal three”. I know what you are thinking … Nobody code like that! Well I hate to burst the bubble (actually not), but this sort of code pops up just about everywhere – I’m serious!
Now that I think back, we were already studying Anti-patterns and Patterns many years before the GOF got together and wrote their book. In the persute of perpetual improvement, I strongly suggest that programmers and designers alike, study Anti-Patterns with the same gusto as Patterns as we can learn as much from successes as we can from failures.
