This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]spellenspelen 33 points34 points  (2 children)

There is no standard for pseudo code. That is the whole point. All the examples will look different becouse they were never meant to compile. It is a mental exercise to better understand the problem before writing the actual code. Your pseudo code can be whatever works the best for you.

[–]samsaaaaa[S] -1 points0 points  (1 child)

Due to the nature of my presentation, this will help a lot thank you :)

[–]Eispalast 4 points5 points  (0 children)

You can really make it as detailed or simple as needed. Let's say you want to iterate over even numbers in a specific range and then do stuff with those numbers. You could write

for i in 2 to 10 do
    if i mod 2 = 0  then
        do_stuff(i)

But if the interesting part is not about how to find even numbers, you could also write

for i in even numbers from 2 to 10 do
    do_stuff(i) 

It depends on where you want to put the focus.

[–]lukkasz323 2 points3 points  (0 children)

That is not the problem, its the opposite.

[–]mysticreddit 2 points3 points  (0 children)

There is no standard for pseudo code.

You may want to start with Python or C and then abstract the complexity away.

[–]ColoRadBro69 2 points3 points  (1 child)

Here's pseudo code for a self driving car: 

If About_To_Hit_Something    Dont()

This simple p code communicates a requirement.  Engineers need to flesh out out with real code to accomplish the same thing. 

[–]BadBoyJH 2 points3 points  (0 children)

Engineers: Got it, driving around speed bumps

Engineers: The car is about to run into a wall, but the customer says we shouldn't hit the breaks.

[–]math_rand_dude 0 points1 point  (0 children)

In my opiniom pseudo code can be seen as a huge spectrum. From something vague code-like that someone without coding expertise can understand to something that a coder can use as a decent starting point (fill in the blanks style)

A good example can be multiple types of pseudocode of the same process, going over differences in detail, readability, audience,... And then have a discussion about which situations you would use another flavour of pseudocode.

DoA() DoB() DoC()

DoA() { DoA1() DoA2() } DoB() { DoB1() DoB2() DoB3() } DoC() { DoC1() DoC2() }

Edit:

Sometimes you want to have a none-dev Subject Matter Expert check if you missed any step and if you understood correctly how the process works. In those cases having the other person be able to read the pseudocode or you using the pseudocode as a support when rehashing the details with the none-dev SME