On decision tables and conditionals

Over the years, I’ve heard a few times about something like Decision Tables (Hillel Wayne):

A decision table is a means of concisely representing branching and conditional computations. In the most basic form, you have some columns that represent the “inputs” as booleans and some columns that represent outputs and effects.

It was usually some variation of teams using something like a truth table to define the logic of their application without using a mess of conditionals. It also turned out that there was a compiler optimization where these tables could be laid out such that figuring out which behavior was appropriate to all the inputs was faster than conditionals would have been.

Wayne doesn’t mention anything like this. But, there is mention of using decision tables with an RSpec macro to verify code behavior with less boilerplate assertion logic. So that’s neat!

If I had to sum up my style of coding, I’d say probably a third of it is about reducing the time I spend reading or writing conditional code. That’s where most of the bugs and frustration are. Pushing them down into the compiler, runtime, or database is a fun exercise too.