We discuss why knowledge of patterns is important to effective creation, implementation, debugging, and maintenance of software; we explain why these patterns have been chosen (and why they are important to your coding efforts); and we offer a table of "symptoms" for those programmers and designers who want to jump right in and play detective.
Why Is It Important to Know Patterns?
Bug patterns are recurring relationships between underlying bugs and signaled errors in a program. Knowledge of these patterns and the symptoms they demonstrate is a tool that will let the programmer not only quickly identify occurrences of a bug, but will help him prevent bugs occurring in the first place.
Just as a good programmer needs to know design patterns-patterns which can be combined and applied in various contexts-a good debugger needs to know the common causes of bugs, and how to fix them.
Bug patterns are related to anti-patterns, which are patterns of common software designs that have been proven to fail time and again. Such "negative examples" of design are an essential complement to traditional, positive design patterns. But while anti-patterns are patterns of design, bug patterns are patterns of erroneous program behavior correlated with programming mistakes. The concern is not with design at all, but with the coding and debugging process.
The concept of using patterns, both positive and negative ones, is not novel to programming. Physicians rely on similar types of recurring relationships when diagnosing disease. The problem is that it can take many years for programmers to learn to recognize these patterns through experience alone.
If we identify such patterns and teach them explicitly, we can leverage the experiences of many programmers to improve the effectiveness of each.
Why These Bug Patterns?
So why did I choose the particular patterns outlined in this article? Why should these bug patterns be of more use to you than others?
Simple. These patterns are among the most frequently encountered. Many of them are introduced into software by common programming errors, whether they are misunderstandings in the conceptual methods used to direct code behavior, or just entry typos.
How the Patterns Are Organized
In this article, to aid in identifying and classifying the following bug patterns, we'll summarize each description using the following form (borrowing some terminology from the medical establishment):
- Pattern name. An easy-to-identify name for the bug.
- Symptoms. Behaviors or results that clue you in to the presence of a bug.
- Causes. The actions, inactions, misdirections, or errors that may be causing the problem.
- Cures and preventions. Methods to fix an existing problem and techniques to keep the problem from raising its annoying head.
Along with each pattern, I'll also discuss broader programming principles and language design issues-such as language expressiveness, static checking, class design, and so on-that may either contribute to or help minimize the occurrence of the pattern. Code samples will be included with each pattern to help the illuminate the problem and ways to correct it.
Related Online Articles:
- Bug Pattern in Java - Agile Methods in a Chaotic Environment
- Bug Patterns in Java - Platform-Dependent Patterns
- Bug Pattern in Java - Saboteur Data
- Bug Patterns in Java - The Split Cleaner
- Bug Pattern in Java - The Impostor Type
- Bug Patterns in Java - The Orphaned Thread
- Design Patterns for Debugging - Maximizing Static Type Checking
- Bug Pattern in Java - Null Pointers Everywhere
- Bug Pattern in Java - Debugging & the Testing Process
- Design Patterns for Debugging
No comment yet. Be the first to post a comment.