#30 - You Can't Write Perfect Software
But Pragmatic Programmers take this a step further. They don't trust themselves, either. Knowing that no one writes perfect code, including themselves, Pragmatic Programmers code in defenses against their own mistakes.
#31 - Design with Contracts
In languages that do not support DBC (Design By Contracts) in the code, this might be as far as you can go—and that's not too bad. DBC is, after all, a design technique. Even without automatic checking, you can put the contract in the code as comments and still get a very real benefit. If nothing else, the commented contracts give you a place to start looking when trouble strikes.
#32 - Crash Early
One of the benefits of detecting problems as soon as you can is that you can crash earlier. And many times, crashing your program is the best thing you can do. The alternative may be to continue, writing corrupted data to some vital database or commanding the washing machine into its twentieth consecutive spin cycle.
#33 - If It Can't Happen, Use Assertions to Ensure That It Won't
"This code won't be used 30 years from now, so two-digit dates are fine." "This application will never be used abroad, so why internationalize it?" "count can't be negative." "This printf can't fail."
Let's not practice this kind of self-deception, particularly when coding.
Whenever you find yourself thinking "but of course that could never happen," add code to check it.
#34 - Use Exceptions for Exceptional Problems
One of the problems with exceptions is knowing when to use them. We believe that exceptions should rarely be used as part of a program's normal flow; exceptions should be reserved for unexpected events. Assume that an uncaught exception will terminate your program and ask yourself, "Will this code still run if I remove all the exception handlers?" If the answer is "no," then maybe exceptions are being used in nonexceptional circumstances.
#35 - Finish What You Start
We all manage resources whenever we code: memory, transactions, threads, files, timers—all kinds of things with limited availability. Most of the time, resource usage follows a predictable pattern: you allocate the resource, use it, and then deallocate it. However, many developers have no consistent plan for dealing with resource allocation and deallocation.
#36 - Minimize Coupling Between Modules
You can see symptoms of this phenomenon in a number of ways:
1. Large C or C++ projects where the command to link a unit test is longer than the test program itself
2. "Simple" changes to one module that propagate through unrelated modules in the system
3. Developers who are afraid to change code because they aren't sure what might be affected
The Law of Demeter for functions attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object's methods.
#37 - Configure, Don't Integrate
First, we want to make our systems highly configurable. Not just things such as screen colors and prompt text, but deeply ingrained items such as the choice of algorithms, database products, middleware technology, and user-interface style.
These items should be implemented as configuration options, not through integration or engineering.
#38 - Put Abstractions in Code Details in Metadata
Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.
Metadata is any data that describes the application—how it should run, what resources it should use, and so on. Typically, metadata is accessed and used at runtime, not at compile time. You use metadata all the time—at least your programs do. Suppose you click on an option to hide the toolbar on your Web browser. The browser will store that preference, as metadata, in some sort of internal database.
#39 - Analyze Workflow to Improve Concurrency
In many projects, we need to model and analyze the user's workflows as part of requirements analysis. We'd like to find out what can happen at the same time, and what must happen in a strict order. One way to do this is to capture their description of workflow using a notation such as the UML activity diagram
Top comments (0)