What is Pseudocode?

We’ve all heard of it, and we’ve all probably done our fair share of it as devs. But what exactly is pseudocode?

Pseudo code is the freeform bridge between syntax and our human thoughts. It’s how we can communicate and form the concepts of an algorithm or program without writing it completely. The way I think of pseudocode is as a tool that we use to communicate ideas, and like with any tool, you have to learn to use it.

Writing out pseudocode with pen and paper is an invaluable tool for clarifying ideas. But when first trying out pseudocode sometimes what makes total sense in your head is total gibberish to someone else.

This frustration lead me to a question: Is there a standard way of writing it per language, in general, or at all?

The short answer that I found was: no. Pseudocode a loose term to describe a free form type of organization - a standard pseudocode would be like a standard brainstorming process, one probably exists, but that sort of defeats the purpose of expressing your individual thoughts.

The long answer I found was that there is no explicit syntax/language for it, but there are some conventional rules that can improve your pseudocode and increase it’s efficacy as a communication tool.

Pseudocode exists on a spectrum between syntax and human language. Generally this means you want to avoid writing in plain english because that leaves too much room for (mis)interpretation.

Another rule that is obvious, but can be broken unconsciously, is flavoring your pseudocode with disparate syntax from multiple languages. If you use multiple languages regularly, your pseudocode might become a javascript-ruby swirl.

I know that swirl is the best soft serve at McDonalds, but this

def occurrences (array, substring)
    let count = 0
    array.each do |x|
        x => {count += the number of times substring  appears in x}
    end 
    return count
end

is anything but tasty.

The things that you shouldn’t do with pseudocode are generally intuitive. So if you’re writing pseudocode and it’s starting to feel too abstract or funky - it probably is.

Avoiding those issues is usually obvious once you've experienced pseudocode a few times, but writing concise and effective pseudocode isn't always as easy.

Here are a few rules that I follow to keep things consistent:

• Write function calls and basic operations in raw syntax: This makes pseudocode much easier to translate into real code, letting you focus on the difficult parts.
• Use proper indentation and brackets for structure and easy translation
• Use reserved words of the language wherever relevent: Structure structure structure.
• Like with your actual programs (hopefully) Use descriptive variable names: This is just good practice for absolutely any programming, and because pseudocode is explicitly for human brains, using names that your human brain can easily recognize is especially important.

What it comes down to is that pseudocode quality is mostly dependent on how clearly it's structured. Writing pseudocode that is well structured can give even an inexperienced dev an immediate (if cursory) understanding of of really complex programs.

Beyond visually structuring your pseudocode and using the fundamental syntax of the language you’re translating to, good pseudocode has a wide range of strong implementations. Take these two examples of insertion sort pseudocode:

One of these is mostly plain english, but can be understood quickly and by even beginners, the other of these is mathematical pseudocode that is heavy in syntax. Both of these are valid and useful pseudocodes of the same algorithm for different purposes. The first one is an introductory teaching tool, and the second one is a more specific guide for implementing insertion sort. Whether you lean towards more semantic vs more syntactic pseudocode is just a product of how you think and what you think about, both are great!

In some cases your pseudocode might be very syntactic and close to the final product, and in others it will be more semantic and freeform - and sometimes it will start loose and get refined with more syntax as the idea develops.

Or you're pseudocode will be light on syntax and still close to the final product because you're using Python!

If you don't write pseudocode often, practice it just for yourself, and see how accurately you can describe your potential or existing programs with different amounts of actual syntax.

your teammates will thank you for saving so much time with your handy pseudocode skills, and you'll thank yourself for improving how you think about code, so write some pseudocode today!