Part of a series of posts explaining programming for the lay-person.
This is part of a series of posts; see the introduction to this series. This entry overviews control constructs, which are part of the dominant imperative paradigm. Some form of them also appear in the functional paradigm as well.
Recall that imperative programming chains together a set of statements in an explicit order: first state your name, then your mission. The simplest order is a simple sequence, each instruction being followed exactly once and only when it appears in the ordering of statements. We call a list of statements combined in that way a basic block. Sometimes, though, we like to be able to have certain statements be executed out of order, or repeatedly, or only under some conditions. Control constructs are ways of adjusting the order in which statements are executed.
A simple example of a control construct is found in the assembly instructions for a dining set I recently acquired. There were four identical chairs, and rather than repeat the description of how to assemble a chair four times the instructions only had one chair’s assembly specified preceded by the words “for each chair”. Those words, “for each chair”, are a control construct. They changed the chair assembly instructions from steps to be followed once only into steps to be followed several times. Another example of a control construct comes from a recipe for baking cookies: “if using self-rising flour …” This means that the following directions might be skipped, depending on the kind of flour used.
I shall discuss particularly common control constructs in later posts. For now I suggest looking for them in the real world, to get a feel for how common they are. “No turn on red”, “beat eggs until stiff”, “preheat to 400 (375 in high altitudes)”, “construct each widget by…”, “Allow an additional 15 minutes during rush hour”, etc. They’re everywhere, so much so that we hardly even notice them. They change if/when/how often we follow other instructions. In programming they’re called “control constructs” and they’re the very lifeblood of imperative programming.