The intent of the design is that there’s a stark dividing line between Check rules and Carry out rules. Actions that get stopped during their Check rules (or prior) failed and any action still going beyond that point has succeeded (whether there were any more rules to be followed) by definition.[1]
Now, unless you’re using unsucessful attempt by rules or are attempting the fairly doomed endeavor of testing whether an action succeeded, this distinction… doesn’t matter a lot.
But what can matter a fair bit, though, is developing and employing consistent habits of where you put what so you don’t sabotage your future self’s ability to apprehend your own code. Ideally, your first guess about how would I have done that? should actually be right.
These principles inform my habits.
Before rules are where you re-dispatch to a different action, as appropriate. Once we’re past considering whether that’s appropriate, any number of other things tappropriate to do prior to the Basic Visibility, Basic Accessibility, and Carrying Requirements rules might happen, but typically not stopping the action because that looks like a job for…
Check rules arewhere you test whether the action should continue and, if not, output an appropriate message and stop the action. Instead rules are where you do those things if there’s a compelling reason you can’t do them in Check rules.
Changing the world state is the domain of (principally) Carry Out rules, but it’s acceptable in After rules. If something really couldn’t be done otherwise, I’d consider a Before or Instead rule, but if the day came that I was considering a Check or Report rule, I’d conclude my thinking had gone off the rails and I should start over.
Output is the domain of Report rules. In a pinch I’d consider an After rule, but I prefer to write a first report rule with stop the action to the common Inform idiom of using an After rule just for customize output and skip the default Report rules.
…unless it’s an action whose whole point is to generate output without changing the world state like examining or taking inventory. The Standard Rules’ norm is to implement those through Carry Out rules and it does no harm.
I’m not saying the above is correct but I am saying that I have benefited from following a scheme consistently.
per my merciless pedantry pledge, there’s a bug in 10.1 by which an explicit
rule failsin anafterrule ends up flouting the definitive behavior ↩︎