Don’t start ordering until you have finished deciding

When programming, it is often the case there are a number of decisions to take, and each one, when acted upon, takes a lot of time (or other resources). In those cases, it is usually better to separate the code into two parts, preferably which also run consecutively. First gather the data and make the decisions, which is usually a non-resource-intensive process, and then, and only then, start requesting the resources and work on them.

This leads to easier debuggability: with a real debugger, it is easy enough to put a break point at the point of using the resources, so one can inspect the decision list before the decisions are executed, so no time is wasted waiting for resources (and it works equally well when the resources are external and lacking), and when using print-and-see debugging, it is easy to put in a “print” statement in the right place, and just break out of the code if the decisions are wrong. It often takes a little more work and a little more thought in separating things out like that, but it pays for itself the first time it has to be modified or when it has to be fixed.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: