Check at the door

Think of it when data arrives from a user, a file, a config or another company’s API, or the same check appears in many places.

In everyday life

Like a passport check at the border. Each traveller is checked once, on the way in; nobody asks for the passport again at every café.

One case

A booking site’s form lets a user type the number of guests. Nothing checks the number on the way in. A user types -1, and the price code multiplies the $120 nightly price by it and saves a booking with a total of -$120.

Check at the door
The ideaKeep it contained
Check at the door

Check data once, where it enters the system from outside, and turn it into a clean, known shape. Code inside can then trust it.

Keep it contained, Habits

Every case

Outside data is wrong in endless ways: blank, too long, the wrong type, or made on purpose to cause harm. If nothing checks it at the boundaryThe edge of your system, where data comes in from outside: a form, a file, another company’s API., each function inside must guess whether to check it, and some will not. The checks that do exist get scattered and repeated, and still miss a path. Check once where the data crosses in, and turn it into a typed value that cannot hold a bad case. Past that point, code trusts it.

The word

Engineers call this

boundary validationCheck data once, where it enters the system from outside, and turn it into a clean, known shape. Code inside can then trust it.

Check outside data once, at the door, and turn it into a clean type. Inside, trust it.

Where this idea leads

Skills that encode it

  • principle-boundary-discipline pstackValidate at system boundaries, parse raw data into domain types there, and trust the types inside with no re-checks.
  • principle-type-system-discipline pstackExternal data is untyped until parsed: put a parse function at every boundary that turns raw input into the typed model.