September 06, 2023
Every step in this process has built on knowing what the plan is for your code. But we have one final planning step that will help ensure you know exactly where you’re going when you do start writing code before it’s time to get into the trenches of writing code: pseudo-coding
Welcome to Back to Basics, a series where we’re going to be reviewing basic engineering concepts that may require a more complex explanation than a quick Google search could provide.
Outline Comes Before Draft — Always
Pseudocode is a way to design code without worrying about syntax. It looks like code, but it doesn’t actually run. Think of it this way: before writing an essay, you create an outline as a map to help you get from one idea to another so that you can follow that map when it’s time to actually start writing the paper.
The goal when pseudo-coding is to look at the project from a bird’s eye view, and then get more granular. To do this, we go through multiple layers of detail.
You already know your project’s intended functionality and your design requirements. The next step is to break that grand overarching task into smaller chunks. When using functional programming languages such as C, these smaller chunks are your files. When using Object Oriented Programming (OOP), each chunk is a class.
For example, if you were writing code to create a digital car, some of the design requirements would include working wheels, an engine, headlights, and seats. Each of those components should be broken into its own class or file.
While it is sometimes simple enough to sketch the different classes or files needed for your project on paper, more complicated tasks necessitate the use of tools. For OOP, there are many different tools to help make class structure diagrams, some of which may come pre-baked into your chosen IDE. IntelliJ IDEA has a built-in class structure tool, but if you’re looking for something separate from your IDE, there are also online options available, including Lucidchart, GenMyModel, yUML, and others.
Key Function Layout
Now that you have your code broken into chunks, it’s time to think about what each chunk needs to do to perform its function. Going back to the car example: each chunk, like the seats, has multiple tasks it must execute in order to fully perform the intended purpose (e.g. car seats should slide backward and forward, tilt, and have a seat belt). In our code, each of those tasks would be a key function, or action that is essential to the file or class.
When pseudo-coding function layout, you don’t necessarily need to think about each detail of how the function works, but rather focus on the parameters and return values you may need and how to manipulate those data points to get the proper functionality.
The last layer is to look at each function and decide whether it needs to be broken into smaller functions, or whether multiple key functions have common features that they need. A simple example would be if you’re averaging a number multiple times, it can be useful to have a small, separate function that does that for you, instead of doing it manually.
On a practical level, most pseudocode should be able to exist on paper. If you feel that you need an IDE to manage syntax, you’ve gone too far. Think in broad strokes, and soon, you’ll have a map to a working program!
The next section of this series will focus on beginning to code, so stay tuned and happy brainstorming!
Click here to read the first installment of Back to Basics: Ideation & Requirements
Click here to read the second installment of Back to Basics: Development Stack
Click here to read the third installment of Back to Basics: Configuring the Development Environment