“…an
atomic plant is so vast, so expensive and so complicated that people cannot
grasp it, and rather than try, they fall back on the assumption that somebody else
checked all the details before it got this far… A bike shed on the other
hand. Anyone can build one of those over
a weekend.” – Poul-Henning
While the blog post I have chosen
does not lead with Bike-Shedding, it is certainly one of the most interesting
examples of “Anti-Patterns” – practices in programming that are counterproductive
to both actual development as well as implementation – and provides a hilarious
anecdote, of which the quote above is from. While perhaps less entertaining, this
post outlines nine types of coding Anti-Patterns and defines what they actually
are, why they are bad, how to avoid them, and provides – my favorite –
examples, among other notes. Most importantly, these concepts are tied to code
smell, and I hope to explain the links between code smell and the practices
that cause it.
For instance, the first Anti-Pattern is Premature Optimization: As the name suggests, it is trying to code for bottlenecks you may have rather than using tried and true methods and finding the actual bottlenecks on runtime. As mentioned, in my own code I have a similar problem where I attempt to write everything perfectly, or in as few lines as possible, instead of building a working a prototype and then cleaning up code after review.
While perhaps not identical to this pattern, the tendency to get hung up on all the possibilities and edge cases just slows development and often the actual execution of the code. Code that has developed in this way is very similar to a code smell known as Speculative Generality, which is defined as excess code created “just in case”. The only difference is that instead of excess optimization code this smell is more interested with future features.
Another relevant example is the God
Class: a single class that contains and controls aspects for an excessive
amount of child classes. When code is structured in this way it makes maintenance
an obvious nightmare. This reflects two code smells most closely, Large Class
and Shotgun Surgery which are tremendously large classes that need to be split
into smaller pieces and the need to fix smaller problems spread across several
classes as a result of another change, respectively.
This trend continues with the Fear
of Adding Classes pattern reflecting the aforementioned Large Class smell;
Useless Class pattern and Lazy Class smell; and the trend continues. What I
wish to express mainly is that these two concepts exist on a continuum with Anti-Patterns
on the development end and code smell on the completed program end. So as we move
forward with the course I’ll try to be cognizant of the Anti-Patterns that lead
to poor code – as well as those which slow development cause of interpersonal
issues which I didn’t get to discuss in this particular post – and how this
poor code exhibits various code smells.
Sources:
From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.