Control Flow Fundamentals

J. W. Rider

J. W. Rider Consulting

October 2004


Once upon a time, no programmer would have ever considered writing a line of code until after the program had been diagrammed with a flowchart.  Flowcharts were the only mechanisms available for explaining what a program did without looking at the actual source code.  Modern programmers have additional tools and diagrams to aide the understanding of program operations.  However, in some situations, the elementary flowchart remains the best choice for communicating what steps are needed to solve a problem and the order in which those steps must be executed.


From a theoretical perspective, a flowchart is a directed graph, or digraph. A graph is simply a collection of nodes (or vertices) and edges (or lines) which connect the nodes.  A graph becomes a digraph when the edges become directional.  Digraphs may be used for a variety of purposes, but in the case of flowcharts, they are used to show control flow. At any one time, the CPU of a computer is executing a single instruction, or a single programming language statement.  That single item is in control of the CPU.  The flowchart depicts graphically the order in which the instructions and statements should be executed in order to solve a particular problem.


The nodes of a flowchart must be connected by directed edges (“arrows”).  There should be no isolated nodes.



The symbols used for the nodes in a flowchart should be applied consistently.







Some seasoned programmers out there may be snickering by now.  Flowcharts may have once been the primary design tool for programmers, but few modern programmers are expected to draw flowcharts.   This is partly due to the effort required to maintain both a flowchart and a program simultaneously when one is modified.  If the flowchart and the program are out-of-sync, programmers quickly favor the source code to understand what the “real program” is doing.


Another reason for the decline of flowcharting for programmers is a matter of picking the right graphic tool for the job.  For object-oriented and visual programming tasks, UML class diagrams are superior to showing the overall program structure.


High-level flowcharts are useful in reaching agreements between customers and developers concerning what steps are necessary to solve a problem, and how those steps should be arranged.  This is especially important in those cases where the program has not yet been coded.


Despite the sense that flowcharts may seem dated, in recent years, flowcharts have been reincarnated for use by programmers in the form of UML activity diagrams, an extension of UML state charts.


Consequently, programmers are now armed with a variety of graphic tools, each one showing a specific aspect of software construction or operations.  All these tools have their uses, and a best situation in which a tool should be applied.