Parse, Don’t Validate

Alexis King’s post “Parse, don’t validate” is the best thing I’ve read in months. And not just for its pitch-perfect use of “cromulent”. Please find some time and commit to reading it all — it will make you a better programmer — but here’s a small taste:

The problem is that validation-based approaches make it extremely difficult or impossible to determine if everything was actually validated up front… The entire program must assume that raising an exception anywhere is not only possible, it’s regularly necessary.

Parsing avoids this problem by stratifying the program into two phases — parsing and execution — where failure due to invalid input can only happen in the first phase. The set of remaining failure modes during execution is minimal by comparison, and they can be handled with the tender care they require.

It sparks in me some new thoughts with regard to my favorite Ben Sandofsky quote:

If the boilerplate gets mind numbing, refactor it into class methods. If that gets to be too much, build some model objects. The goal is to iterate toward your domain model. There’s a reason Apple’s frameworks only get you 80% of the way there. That remaining 20% is called ‘Your App.’

King’s post makes concrete for me how futile it is to pass and occasionally validate data in pursuit of this goal. It’s only through the successive parsing of our data that we iterate towards our domain model. Validating just rearranges deck chairs on the Titanics of our ever-growing codebases.