9
$\begingroup$

For GCSE CS in the UK, students have to analyse, design, code, test and review a solution to a problem.

For the design section of their project, students have to plan out the algorithm for each part of their coded solution. They can choose to use pseudocode or flow charts as long as they show the logic and programming constructs that they'll use.

Here's a link to a typical task that students have to complete

My question is this: which is better for planning a set of algorithms: pseudocode or flow charts?

By better I mean faster, more accurate, easier to understand and/or gives a better chance of scoring higher marks.

Improve this question
$\endgroup$
6
  • 2
    $\begingroup$ Your link doesn't go to a task prompt $\endgroup$
    – Ben I. ♦
    Commented Jun 14, 2017 at 14:41
  • $\begingroup$ It's the "Specimen NEA Project Brief" on the link in the question. There's also a link to the exam board's pseudocode spec at the bottom of the "Sample Assessment Materials" document $\endgroup$
    – pddring
    Commented Jun 14, 2017 at 15:46
  • $\begingroup$ Books like MIT's Introduction to Algorithms use pseudo-code so I'd go with that. $\endgroup$
    – user2121
    Commented Jun 14, 2017 at 17:36
  • 2
    $\begingroup$ Because OR allows both the answer is YES! Both! Graph theory would say that the two are interconvertible, and they are. One shows things the other doesn't. Can't get by without both. $\endgroup$
    – user737
    Commented Jun 14, 2017 at 19:38
  • $\begingroup$ Shouldn't an answer to this require knowledge of how GCSE UK (whatever that is) is graded? $\endgroup$
    – Ellen Spertus
    Commented Jun 15, 2017 at 3:09

5 Answers 5

Reset to default
10
$\begingroup$

Neither is always better, and both have their strengths.

The idea of scoring higher marks as a criteria for better is going to be unpredictable without knowing who is granting those marks. Someone who is heavily in favor of one style over the other may grant higher marks to low quality uses of their favored style than they would to high quality answers in the other style.

The idea of being faster is both personal and situational. If someone is more comfortable using one over the other, they will usually be faster with that style, whichever it is. Some projects seem to do better in one style than they do in the other, even when the person doing the project is proficient in both styles. This is related to the strengths and weakness of each style.

Pseudo code is more free-form, and allows one to concentrate on how to solve the problem or design the algorithm without having to choose the proper symbol to draw, or how to leave room for other branches on the chart. Pseudo code is also closer to the programming statements that will be used, eventually, to implement the algorithms, and can speed up the coding process. Being free-form makes it harder to spot missed checks on conditionals. It is also harder to see the overall pattern of a larger algorithm in pseudo code.

Flowcharts diagram the algorithm in a visual manner that makes the entire algorithm visible. When the logic gets complex, this visual representation enhances the ability to trace all branches and confirm that every conditional has been fully handled. It can also show cases where things are getting to complex, and need to be re-factored. The downside to this visual representation is that the creator frequently needs to interrupt their work on the algorithm to make adjustments to the chart, or to redraw sections that no longer fit on the page/screen they are using. These points are even greater detractors when the flowcharts are created on paper rather than in a program designed for flowcharts.

The apparent speed gains from pseudo code's closeness to the final language can be offset by the error checking, and corrections needed, but not spotting logic error in the planning, which is one of the strengths of a flowchart. In addition, the larger picture view provided by the flowchart that can lead to re-factoring, can lead to more compact and efficient code, which is a gain every time the program is executed, even if it took longer to code the first time.

Ideally the students should be taught each method, using exercises that are both a good fit and a bad fit for that method. After leaning the two methods they should have exercises that help them learn how to select the proper one for a given situation. While it may not be appropriate for the classroom, often a programmer on a larger project will use both methods: the flowchart to see the whole picture, and plan the program's overall flow, and pseudo code for many of sections seem to be compact or straight forward.

Bottom line is that the best one to choose is the one that gets the job done right the first time. A fast solution, which then needs lots of corrections is not so fast after all, and a pretty picture of the program can still have logic errors if the programmer is not looking at the real problem the correct way.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Yes, they need both. I love to show students how if they draw the flowchart correctly, they create pseudocode by simply copy-pasting the text from the flowchart symbols, in order, and it turns out. Add a few End-Ifs where the closing lines are in the flowchart and you are done. If you cannot do the copy-paste, your flowchart is NOT Structured, you cannot write code from that. I like to say that if a flowchart was in another language, you could probably still figure out what was going on, tell a decision from a loop, etc. Good luck on that with pseudocode! Both are interchangeable and needed. $\endgroup$
    – user737
    Commented Jun 14, 2017 at 19:37
3
$\begingroup$

Both are a requirement of one of the courses that I teach. I like to start with a flowchart, as (for all the reasons mentioned by @GypsySpellweaver already) they provide a good visual representation of the problem to be solved, and can help then to generate the pseudo code.

Value of flowcharts

Although I have seen it argued that flowcharts are somewhat outdated, I think they still have value due to:

  • the visual representation element.
  • they may also be used in manufacturing to lay out the process for creating a product.
  • they force the creator to be succinct in the description, reducing the verbosity many students like to include in pseudocode.
  • The symbols have meaning that doesn't need to be explained with words
  • they are language independent

Expanding their use

Regarding the last point: Once the solution is coded in your language of choice, I like to show the solution in a number of different languages: Fortran, Pascal, C, Java, Python. It is interesting to see how similar the solution something to Fibonacci will be in each of these, and it gives (imo) learners some confidence that, once they master one language, and the concepts involved in software development, they may be better able to learn additional languages in the future.

Equally, providing some code in Fortran and having them generate a flowchart and code in your target language can be an interesting exercise. Apologies for migrating tangentially here, but I'll assert that it is still related to both pseudocode and flowcharts :)

Free Tool for Flowcharts

A really nice FREE tool is draw.io. I've tried many, but settled on this one as it is free and is stored in the cloud, so they can work from any computer on a work-in-progress.

which is better for planning a set of algorithms: pseudocode or flow charts?

Summary

I would use both- the flowchart for clarity, and the pseudocode as a step-by-step guide for the code. Neither is better, and both have their merits.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ If the flowchart is laid out correctly (down, with nested parts indented to the right) then you can create the pseudocode by simply copying and pasting each line in sequence from the flowchart directly to a text editor. No rearrangement or thinking whatsoever is required. The only difference between a branch and a loop is which way the connecting line goes: up or down. These lines provide the "End If" and other structural parts. This is the magic of using these two techniques. It is a preview of how the same program in any language is "the same", which amounts to a spiritual revelation. $\endgroup$
    – user737
    Commented Aug 30, 2017 at 13:54
  • $\begingroup$ While it is possibly to create structured flowcharts, we are discussing total novices here. The flowcharts that they produce, will be used to create goto ridden code (see goto considered harmful — Edgar Dijkstra ), or it will be ignored, or become a grate source of frustration. $\endgroup$
    – ctrl-alt-delor
    Commented Dec 5, 2018 at 8:28
3
$\begingroup$

The other answers are already spot-on, but I wanted to offer another way to think about it...

My question is this: which is better for planning a set of algorithms: pseudocode or flow charts?

By better I mean faster, more accurate, easier to understand and/or gives a better chance of scoring higher marks.

Like many things in programming, pseudocode and flow charts are both tools that a programmer uses to accomplish their overall goals.

It doesn't make a ton of sense to ask which tool is better overall. A carpenter doesn't ask, "which one is better: a hammer or a saw?" The answer is that they're different tools, used for different jobs.

In my experience, here's how I'd use each:

  • Flow charts are good at showing high-level relationships. "System ABC sends message XYZ to service 123, which calls library 456..."

  • Pseudocode is good for, well, mocking out code. "We're going to use a for loop here but we don't need to waste time on the absolutely correct syntax right now, so let's use pseudocode."

So, students should use whichever tool is best suited to the particular problem they're faced with, or even a combination of both. It's not an either-or thing.

I should also note that learning about one tool makes it easier to learn about other tools in the future. The carpenter learns about both the hammer and the saw, and that knowledge will later help them learn about wrenches. Similarly, learning both flow charts and pseudocode makes it easier to learn about other topics in the future. "This UML stuff sure looks similar to flow charts I learned about before!" "I need to translate this program from one language to another? I know, I'll translate it to pseudocode first!"

Improve this answer
$\endgroup$
1
$\begingroup$

While both notations have their use, I would only use flow charts when the algorithm lends itself to it, namely when the algorithm is made of loops and conditionals.

If your algorithm is recursive for instance, or rely fundamentally on a particular data structure (for instance a stack or a queue) then flowcharts won't help you.

In my experience I found that flowcharts are useless except for the most simple algorithms, but work very well to model user interactions or protocol (i.e. as like simplified UML sequence diagrams or finite state machines).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Flow charts are about goto not about loops and conditions. I do agree with the last paragraph though. $\endgroup$
    – ctrl-alt-delor
    Commented Dec 5, 2018 at 8:23
0
$\begingroup$

To answer the question, first look at what level each language is.

We have

  • The language that the problem will be implemented in
  • …
  • Assembler
  • Machine code (Lowest level)

Where do flowcharts and pseudo code fit in.

  • Pseudo code
  • The language that the problem will be implemented in
  • …
  • Flow charts
  • Assembler
  • Machine code (Lowest level)

Flow charts: Graphical high level assembler, or at best python with gotos. It is useful if you are writing a program for a human to follow. E.g. procedures in a factory (but please get a software engineer to do it in a structured way).

Pseudo code: Once the un-compilable high-level language, but then we made compilers. It is still useful for learner programmers. They can write the program, without worry about the language, comment the pseudo code, and then inter-leave with real code. (Trouble is this is counter productive for an experienced programmer, for most tasks.)

In summary

Both are a terrible design tool. Real programmers don't use them for designing programs. However pseudo code is a very good learning tool. Use pseudo code in the classroom, and for the NEA.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ As a "real programmer" with a few decades of production experience I can report that some programmers do use both tools often. Personally, I often use them on paper before I even approach the keyboard for larger projects. Frequently the quality of the code and the time-to-project-completion have a positive correlation to the usage of such tools by other programmers. $\endgroup$
    – Gypsy Spellweaver
    Commented Dec 5, 2018 at 10:08
  • $\begingroup$ @GypsySpellweaver I have been programming since 1982, and professionally since 1995. I have never seen anyone use a flowchart to help them to design a high-level computer-program. Unless forced to by management. I have seen other diagrams used, some have proved useful. I have seen pseudo-code effectively used when it is much higher-level, than the coding language. I have also seen it effective when the programmer is not fluent in the language they are coding it. Experts tend to use a language they know well, as as pseudo code. There is no value in retaining this pseudocode, except for the NEA. $\endgroup$
    – ctrl-alt-delor
    Commented Dec 6, 2018 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.