Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Deficient Testing Support
I’ll end my tirade on bad code signs with a word about testing. Unit tests are becoming standard, but I wouldn’t go as far as saying that any code lacking unit tests is deficient. Other methods of testing are also acceptable, especially for legacy code. For example, the liberal use of assertions in the code, or the provision of a framework for regression testing, can often provide a solid testing infrastructure. Also, programs implemented as filters or programs providing a scriptable interface can also be easy to test. On the other hand, when it’s obvious that no one ever spent a thought on how the code will be tested, and the code defies reasonable attempts to test it, then you’ve got a problem on your hands.
Many of the bad code traits I’ve identified may seem trivial to you, and many indeed are. Some can even be superficially corrected with a code formatting tool like indent. However, remember we’re talking about ways to spot bad code here, not ways to identify good code. These traits are simply danger signs. If those who wrote the code weren’t motivated enough or didn’t pay enough attention to keep the simple things in order, you can be sure that many worse issues will be lurking in it.
Old maps were marked with the phrase "Here be Dragons" to help seafarers steer away from dangerous places; in programming the best way to avoid dealing with bad code is to avoid writing it.