You can’t write Perfect Software

No one in the brief history of computing has ever written a piece of perfect software. Pragmatic Programmers don’t trust themselves, either.

Design by Contract

A correct program is one that does no more and no less than it claims to do. Use:

Design with Contracts

Write “lazy” code: be strict in what you will accept before you begin, and promise as little as possible in return.

Implementing DBC

Simply enumerating at design time:

Assertions

You can use assertions to apply DBC in some range. (Assertions are not propagated in subclasses)

DBC enforce Crashing Early

Invariants

Dead Programs Tell No Lies

All errors give you information. Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

Crash Early

A dead program normally does a lot less damage than a crippled one.

When your code discovers that something that was supposed to be impossible just happened, your program is no longer viable.

Assertive Programming

If It Can’t Happen, Use Assertions to Ensure That It Won’t

When to Use Exceptions

Use Exceptions for Exceptional Problems

What Is Exceptional?

The program must run if all the exception handlers are removed If your code tries to open a file for reading and that file does not exist, should an exception be raised

How to Balance Resources

When managing resources: memory, transactions, threads, flies, timers—all kinds of things with limited availability, we have to close, finish, delete, deallocate them when we are done.

Finish What You Start

Nest Allocations

Objects and Exceptions

Use finally to free resources.

Based on The Pragmatic Programmer Book by Andy Hunt and Dave Thomas