Expressing algorithms in unambiguous, programming-language-agnostic terms.
A number of tasks in this bootcamp focus on reading or writing pseudocode. Pseudocode is a set of practices and notational conventions used to express computational processes in a non-programming-language-specific form, but usually with the aim of facilitating or documentating implementation in one or more programming languages.
Pseudocode shares its primary aim with flowcharting: expression of a procedure in a clear, unambigous form, built on a relatively small vocabulary of symbols that a reader may be assumed to know. Pseudocode differs from flowcharting primarily in the emphasis on a textual, rather than graphical, representation of the process or algorithm. Another difference is that while flowchart symbols are mostly standardized, there isn’t a formal or de facto standard syntax for pseudocode; instead, pseudocode typically employs a combination of natural language and mathematical notation.
The guidelines and rules below have been formulated with the following aims in mind:
Applicability in the workplace
Like coding style guides, common practices for pseudocode differ between organizations. In fact, in our experience, most development organizations don’t have formal style guides for pseudocode. Nonetheless, our intent is that the practice in reading and writing pseudocode that participants get in this bootcamp will be valuable not only in the bootcamp, but in the participants’ eventual workplaces.
Markdown authoring
Any strict requirement or constraint declared in this page is intended to be satisfiable using Markdown, with some embedded HTML for subscripts, superscripts, etc. (Of course, a good set of Markdown extensions, such as those for tables, footnotes, definition lists, and $\LaTeX$ mathematical notation—all of which are available in the kramdown Markdown processor used by default in GitHub Pages—will usually make the task easier.)
Unambiguous communication
A central goal, when writing pseudocode, should always be to communicate the process clearly, with as little room as possible for misunderstanding. But our aim here is even higher: We want our pseudocode, in a sense, to make the algorithms that they express come to life. This can only happen when the reader isn’t distracted—by questions on undocumented assumptions, confusion caused by the use of poorly defined symbols, inconsistencies in typography and formatting, etc.
Note that there are recognized experts in the fields of computer science and software engineering who advocate the use of programming language code over pseudocode. For example, Robert Sedgewick, the author or co-author of several influentual texts on algorithms, has recommended the Java language for expressing algorithms, even when the intended implementation is in other languages. Nonetheless, we find significant value in the practice of writing pseudocode, and the inclusion of pseudocode in technical documentation.