<p>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.</p>

<h2>Value of flowcharts</h2>

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

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

<h2>Expanding their use</h2>

<p>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.</p>

<p>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 :)</p>

<h2>Free Tool for Flowcharts</h2>

<p>A really nice FREE tool is <a href="http://www.draw.io" rel="nofollow noreferrer">draw.io</a>.  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.</p>

<blockquote>
  <p>which is better for planning a set of algorithms: pseudocode or flow
  charts?</p>
</blockquote>

<h2>Summary</h2>

<p>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.</p>

CC BY-SA 4.0
2018-12-05T08:28:40.490Z
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.
ctrl-alt-delor
CC BY-SA 3.0
2017-08-29T22:57:13.430Z
2017-08-29T22:57:13.430Z
srattigan
<p>The other answers are already spot-on, but I wanted to offer another way to think about it...</p>

<blockquote>
  <p><strong>My question is this:</strong> which is <em>better</em> for planning a set of algorithms: pseudocode or flow charts?</p>
  
  <p>By <em>better</em> I mean faster, more accurate, easier to understand and/or
  gives a better chance of scoring higher marks.</p>
</blockquote>

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

<p>It doesn't make a ton of sense to ask which tool is <strong>better</strong> 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. </p>

<p>In my experience, here's how I'd use each:</p>

<ul>
<li><p>Flow charts are good at showing high-level relationships. <em>"System ABC sends message XYZ to service 123, which calls library 456..."</em></p></li>
<li><p>Pseudocode is good for, well, mocking out code. <em>"We're going to use a <code>for</code> loop here but we don't need to waste time on the absolutely correct syntax right now, so let's use pseudocode."</em></p></li>
</ul>

<p>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.</p>

<p>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. <em>"This UML stuff sure looks similar to flow charts I learned about before!"</em> <em>"I need to translate this program from one language to another? I know, I'll translate it to pseudocode first!"</em></p>

CC BY-SA 3.0
2017-08-29T23:32:46.763Z
2017-08-30T16:39:47.647Z
2017-08-30T16:39:47.647Z
Kevin Workman
<p>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.</p>

<p>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.</p>

<p>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).</p>

CC BY-SA 4.0
2018-12-05T08:23:48.860Z
Flow charts are about `goto` not about loops and conditions. I do agree with the last paragraph though.
ctrl-alt-delor
CC BY-SA 4.0
2018-12-03T07:47:46.510Z
2018-12-03T07:47:46.510Z
Kim Nguyễn
<p>To answer the question, first look at what level each language is.</p>
<p>We have</p>
<ul>
<li>The language that the problem will be implemented in</li>
<li>…</li>
<li>Assembler</li>
<li>Machine code (Lowest level)</li>
</ul>
<p>Where do flowcharts and pseudo code fit in.</p>
<ul>
<li>Pseudo code</li>
<li>The language that the problem will be implemented in</li>
<li>…</li>
<li>Flow charts</li>
<li>Assembler</li>
<li>Machine code (Lowest level)</li>
</ul>
<p>Flow charts: Graphical high level assembler, or at best python with <code>goto</code>s.
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).</p>
<p>Pseudo code: Once the un-compilable high-level language, but then we made compilers. It is still <strong>useful for learner programmers</strong>. 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.)</p>
<h1>In summary</h1>
<p>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.</p>

CC BY-SA 4.0
2018-12-05T10:08:49.227Z
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.
Gypsy Spellweaver
CC BY-SA 4.0
2018-12-06T20:42:15.300Z
@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.
ctrl-alt-delor
CC BY-SA 4.0
2018-12-05T08:21:36.650Z
2018-12-05T08:21:36.650Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>Neither is always better, and both have their strengths.</p>

<p>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.</p>

<p>The idea of being <em>faster</em> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <em>larger picture</em> view provided by the flowchart that can lead to re-factoring, can lead to more compact and efficient code, which is a <em>gain</em> every time the program is executed, even if it took longer to code the first time.</p>

<p>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.</p>

<p>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 <em>picture</em> of the program can still have logic errors if the programmer is not looking at the real problem the correct way.</p>

CC BY-SA 3.0
2017-06-14T15:35:38.633Z
2017-06-14T15:35:38.633Z
Gypsy Spellweaver
<p>For GCSE CS in the UK, students have to analyse, design, code, test and review a solution to a problem.</p>

<p>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. </p>

<p><a href="https://qualifications.pearson.com/en/qualifications/edexcel-gcses/computer-science-2016.coursematerials.html#filterQuery=category:Pearson-UK:Category%2FSpecification-and-sample-assessments" rel="noreferrer">Here's a link</a> to a typical task that students have to complete</p>

<p><strong>My question is this:</strong> which is <em>better</em> for planning a set of algorithms: pseudocode or flow charts?</p>

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

CC BY-SA 3.0
2017-06-14T14:41:53.680Z
Your link doesn't go to a task prompt
Ben I.
CC BY-SA 3.0
2017-06-14T15:46:30.557Z
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
pddring
CC BY-SA 3.0
2017-06-14T17:36:22.937Z
Books like MIT's [Introduction to Algorithms](https://books.google.co.uk/books/about/Introduction_to_Algorithms.html?id=i-bUBQAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y) use pseudo-code so I'd go with that.
user2121
CC BY-SA 3.0
2017-06-15T03:09:27.393Z
Shouldn't an answer to this require knowledge of how GCSE UK (whatever that is) is graded?
Ellen Spertus
CC BY-SA 3.0
2017-10-06T11:42:32.757Z
@user737 Flow charts are interchangeable with a much lower-lever language than most pupils are programming it. For Pseudo code to be of use, it needs to be a higher level than the one they are programming in.
ctrl-alt-delor
<algorithms><pseudo-code><flowcharts>
Pseudocode or Flowcharts?
# Pseudocode or Flowcharts?

(Asked by: username_0 on 2017-06-14)

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](https://qualifications.pearson.com/en/qualifications/edexcel-gcses/computer-science-2016.coursematerials.html#filterQuery=category:Pearson-UK:Category%2FSpecification-and-sample-assessments) 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.

**Tags:** algorithms, pseudo-code, flowcharts

> **Comments:**
> **username_1**: Your link doesn't go to a task prompt  
> **username_0**: 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  
> **username_2**: Books like MIT's [Introduction to Algorithms](https://books.google.co.uk/books/about/Introduction_to_Algorithms.html?id=i-bUBQAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y) use pseudo-code so I'd go with that.  
> **username_3**: Shouldn't an answer to this require knowledge of how GCSE UK (whatever that is) is graded?  
> **username_4**: @user737 Flow charts are interchangeable with a much lower-lever language than most pupils are programming it. For Pseudo code to be of use, it needs to be a higher level than the one they are programming in.  

---

## 5 answers

### Answer by username_8 on 2017-06-14. Score: 10 | Accepted answer

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.


---

### Answer by username_5 on 2017-08-29. Score: 3

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](http://www.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.

> **Comments:**
> **username_4**: 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.  

---

### Answer by username_6 on 2017-08-29. Score: 3

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!"*


---

### Answer by username_7 on 2018-12-03. Score: 1

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).

> **Comments:**
> **username_4**: Flow charts are about `goto` not about loops and conditions. I do agree with the last paragraph though.  

---

### Answer by username_4 on 2018-12-05. Score: 0

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 `goto`s.
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.

> **Comments:**
> **username_8**: 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.  
> **username_4**: @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.  

---

