Pseudocode and Flowcharts
Flowcharts and pseudocode are two tools software designers and developers use to plan and document code. Both are useful techniques to quickly capture programming ideas and describe program flow. In this chapter, we take a brief look at both approaches as applied early in the development cycle.
The prefix 'pseudo' means 'not genuine; false'. However, there is no negative connotation to pseudocode. It simply means that it is not actual code. Programming languages have a rigorous syntax that must be followed. If the rules of the language are broken, syntax errors will prevent compilation/interpretation. There is no such syntactic requirement with pseudocode which makes it a useful tool to begin or supplement the development process.
A primary benefit of pseudocode is it enables a developer to capture ideas quickly and be very productive while describing program operations. While writing pseudocode, the programmer can record progress much more quickly than if s/he were concerned with complying with syntax rules of a language. It can also highlight problems and omissions not discovered prior to the pseudocode step.
With pseudocode there are no strict rules. Developers describe code using expressions similar to standard language. While not necessary, it is common for pseudocode to be written with the targeted language in mind. For example, pseudocode written for C++ programs would likely, at least remotely, resemble actual C++ code. Whereas, pseudocode written for Python may have some of the features of the Python programming language.
In the example below, as beginners at this point in the course, we presume minimal knowledge of Python syntax. Therefore, our pseudocode will be more 'English-like' instead of resembling Python code. With experience, pseudocode may become more and more like the targeted language until the point that it is almost code itself.
Let's consider an example programming challenge and see how the pseudocode appears. Suppose we are writing an application to calculate the total pints of strawberries sold in a given time frame. The pseudocode might look something like that below.
And this is the Python program produced by starting with the pseudocode. Notice how the actual code is not entirely unlike the pseudocode. Also note that line 7 in the code does not exist in the pseudocode. To use total_sales_data like we do on line 12 it needs to be initialized which is performed on line 7. This is a good example of detail that is not required in pseudocode. However, if it occurs to you at the time of writing pseudocode, include detailed information. Just don't allow excessive concern for detail to impede the more relaxed progress while writing pseudocode.
Some senior developers might argue that detail is better left out of the 'conceptual' pseudocode. Personally, I prefer to include 'naturally occurring' detail at the time of writing the pseudocode. However, it is more important to keep momentum going while working through the pseudocode process than to strive for detailed accuracy which may slow the progress. The code produced from the pseudocode:
Here's the output.
Using flowcharts is another productive strategy to improve efficiency and efficacy of the software development processes. Flowcharts have dual utility. They are constructed prior to writing code as a planning aid and to make the code writing process more efficient and correct. Flowcharts also have the benefit of being program documentation which can be consulted during planning, testing, and maintenance processes. For our purposes, flowcharts should always be constructed BEFORE writing code as a substantial tool for understanding and refining program logic. Flowcharts are built using common and generic symbols to represent common program operations.
Unlike pseudocode that can have a syntactic flavor, flowcharting symbols are consistent across all programming languages making flowcharts very portable. Also, a developer with minimal or even no experience in the target language should have little difficulty following program flow as illustrated in a flowchart.
The most common mistakes made with flowcharts are not using a decision symbol (diamond) to represent ALL decisions in code. And, all diamonds must have at least (and usually only) two exit lines. A line is required to represent TRUE and FALSE conditions, thus two exit lines. Remember, diamonds are a flowchart's best friend.
See the chapters Selection and Repetition for nine more examples of classic flowcharts.
The tool Visio from Microsoft was used to produce the flowchart above. It is powerful and capable of producing high-quality results. Visio is available for free download from MADTT. The learning curve for Visio is a little steeper than it is for some other alternatives. For all of the flowcharting tasks in this class we will use diagrams.net. It is a free online flowcharting tool that is quite easy to learn and produces great results.