Matvii Hodovaniuk Notes

A Pragmatic Paranoia

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.

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.

← Home