Hello all.

I have a discussion question about pseudocode this week in my computer science class. I thought I'd open it up to this community since many people on this site have varying degrees of experience in the arena of software and content development. So, in my class we are exploring what are the different examples or methods of writing pseudocode, what are the different rule sets, why it is useful and how it can be applied when making an algorithm.

I promise you aren't doing my homework, you would be helping me to better understand the subject and enlightening me in a way that will make me a better developer in the end. Plus, my homework this week is writing two Java programs, so I'm kinda on my own with that anyway.

What are your experiences with pseudocode and how have you applied/written/transitioned it into an algorithm or code for a program? Thanks a lot and excited and eager to read responses!

Hey! I work as a professional software engineer. Since I work primarily in Java, I don't write too much pseudocode. For me, the method name IS the abstraction. If I know there's some logic I need to write but I want to get the overarching steps down first, I'll go ahead and put it into the code as a method and implement it later. Everyone works differently, though.

Now that I'm certain that we’re not doing your homework…

When it comes to writing noncomplex programs, I often use pseudocode to make sure that my reasoning and logic is valid. This often includes drawings or sketches that can help visualize how the data will be manipulated or how data structures interact with each other. This helps me visualize the workflow and make sure that everything’s running smoothly. For these, I often use a Swift-like or Python-like syntax, which is pretty lax and is a neat way of outlining the steps you want your program to take. I don't pay too much attention to the rules I use on this methodology. Most of the time, though, I write most pseudo codes using a mix of languages that help outline what I want. From that, I then work into polishing into the program by writing it out neatly in the IDE.

For more serious or complex methods, I like to start with some sort of pseudo-pseudocode, in which I outline the main steps of the method or workflow in plain English. From there, I evaluate whether I could extract some portion of the algorithm into a separate function. Then, I’d divide the large pseudo-pseudocode in smaller sections, which I would then work in a way that’s pretty similar to the workflow outlined in my first paragraph.

Overall, I find it quite useful to make sure that your logic is sound and that the final product will behave appropriately, given the fact that you implemented everything correctly. Another bonus I often find from this is that it gives me the opportunity to evaluate whether some piece of code needs to be refactored or extracted as a new function and make sure that I’m not overloading functions with excessive amounts of code.

Not only do I use pseudocode before implementing functions, but I occasionally find myself working through pseudocode based on other people’s works that I wish to understand or revise. One thing I learned from my programming professor is to read out code as ”paragraphs, ” which might seem weird to explain in this short message but has definitely helped out throughout the years. It’s where you analyze one or two lines of code and, in your own words, describe what’s happening. You could call it sort of inverse pseudocode, where you use it to translate code that’s been written already into something that’s human-friendly.

Of course, as everything in life, pseudocode can have its shortcomings. There have been a few scenarios in which pseudocode hasn’t been so helpful. For example: trees. I’ll just never understand them at all.

Thanks much for posting on a topic like this one. Looking forward to more replies!

Edit: I would’ve been more specific, abundant, and provide some examples, but writing this from my phone greatly discourages me from doing so. Might do so in the near future, if I remember it.

Thanks for this response. There's a wealth of very useful perspective in it, and I greatly appreciate it. The idea of inverted or reverse pseudo code is very interesting too, because I often find I have to explain the functions of a program, sometimes not one that I designed, and that method of thinking about it is helpful when forming instructions.

Y'know, seeing this topic again, I remember how my programming professor sometimes told us to think of programming not unlike reading a book, how we should see any chunk of code or algorithm and be able to interpret it as something coherent. It's a skill that I'm definitely not a master of, but I often find it useful to take a few moments and understand line-by-line what's happening in an algorithm. We could call this concept creating "phrases" based on what the code does. Once that's fairly good and set in my mind, I then transition into a couple of lines of code at a time (remembering what each line was meant to do) and create what we could call a "sentence," so to speak. Something that would summarize pretty well what a couple of lines of code would accomplish. By the time I've made up many sentences for most of the algorithm, I'd then join them up and create a "paragraph," which would accurately describe what's going on in the algorithm.

Now, I know this is quite a conceptual thing to do, and something that could be time-consuming, but doing so more and more often can lead to "trusting yourself more" when writing up some chunk of code. For instance, in my early programming years, I can vividly remember how I would write up `console.log`s after every single thing I'd do to a variable, even if it was just adding two variables together, to ensure that everything was going on fine (this was long before I knew what debuggers and breakpoints were). By exposing myself to more and more pieces of code and programming problems, I slowly let off these...weird habits. I eventually caught up on how computers behave and that I could rely on them doing what I tell them to do a bit more often, and wouldn't need to check on variables on literally every step of the algorithm.

Nowadays, it's become pretty second-nature to read, understand and document what I'm looking at, so it takes far less `console.log`s to pinpoint what's going on if there's some odd behavior with the code that I'm working with.

But, to tie this up with the whole pseudocode topic, I can assure you that I find it really useful, and have become more used to, to write up comments at least at the "sentence" level, and the algorithm's gist of what it does being the "paragraph"-level explanation. I'd often find myself writing up things as a bunch of steps:

`-- Initializing some internal variables`
...
`-- If we've been given a JSON object, let's destructure it and get its first-level Key-Value pairs`
...
---> `-- Let's begin by setting delimiters after each Key-Value pair...`
...
---> `-- Then, we check whether everything between START_INDEX and END_INDEX is a complete JSON object`
---> `-- by ensuring that the number of "{" matches the number of "}" in our Key-Value substring.`
---> `-- If they don't match, let's move the END_INDEX a bit farther to the left.`
...
---> `-- Now that we have a coherent substring that contains a Key-Value pair, let's add it to our output table.`
...
`-- Else, let's just return the string as-is`
...

That was just a couple of the steps recalled from the top of my head regarding one of my latest feats: taming MSSQL 2012 to turn a JSON-formatted string into a one-level table. Oh, the joy...

Aside from these "paragraph"-level pseudocode, I'd rarely leave comments that would explain just one line. Mostly, it's because of the simplicity of the chunk of code itself. Or, sometimes I would write per-line comments if I'm using a tool that pretty much everyone else around is not too familiarized with, to help us all with reading through the code at a later time...except for that one time where I left them in to explain my coworkers how the coalescing function worked, although they were extremely familiar with the nil-coalescing operator...

Oh dear, there I go again boring you all with my long and uninteresting stories...

Anyways, how would you go around at understanding some algorithms, if I may ask? I'm very eager to read up from other users on this.


PS: Please, ALWAYS leave some pseudocode around SQL scripts, especially if they do something more than select certain values from a table.

*content removed*

*Modmin Edit* (1/30/2021 5:39:34 AM)

I do often see them as stories or as recipes, and as a writer I can appreciate how you break it down into "sentences" and "paragraphs" which my notes and pseudocode likely often resemble. I'm sure I have a lot of weird habits, having never programmed professionally or outside of school.

Because I am a baker, I have to be very procedural and exact, which was easy for me to learn since before becoming a baker I was an auditor. So I'm adept at breaking down anything procedurally and mathematically oftentimes, and putting it into words is second nature. I'm sure anything I program though would seem clunky, perhaps jumbled and inefficient, because I've never done actual work as a programmer. To me, it makes sense to me to view an algorithm as something like a mix of a story and recipes, since there are generally several components involved to focus on, and different aspects perform different functions to achieve a combined result.

From what I know of SQL and what I understand of most databases, I can imagine how necessary it would be to annotate the code.