How do I understand flowcharts

When would I use pseudocode instead of flowchart?

I am a student working with various programming techniques and I came across pseudocode and flowchart. I know both of them are used to think through the problem before actually programming, but I have a couple of questions about that.

  1. When would I use pseudocode for planning and when would I use flowcharts? Or is it better to do both before actually programming. Especially for a small arcade game in JAVA as this is my next project.
  2. I've found the pseudocode to be very similar to the actual code rather than the flowcharts. Would this improve the pseudocoding as you are essentially copying / pasting the pseudocode into your program (of course you have to adapt it to the language. I get that part).
  3. Is it convenient to use both when programming? Especially the same game mentioned earlier. Many Thanks.


Flowcharts and pseudocode often have the same expressiveness, but differ in the linearization. Pseudocode is linear (that is, a series of lines of instructions), a flowchart is not. Therefore, flowcharts are a higher level of abstraction to use before writing pseudocode or for documentation purposes.

Flowcharts, in my opinion, have two strong advantages over pseudocode: First, they are graphical. Many non-technical people are terrified of structured text but not of graphical descriptions, so flowcharts suit them a lot better. Second, flowcharts are much better at expressing meta-considerations such as the representation of the main execution line as opposed to branches.

Your questions in detail:

  1. For a really complicated problem, you would use flowcharts first and then pseudocode. Both are optional if you feel confident enough.
  2. Yes, pseudocode has the advantage that it can be merged with real code. For example, Steve McConnell strongly recommends writing methods in pseudocode first and then leaving the pseudocode as comments in the code.
  3. I've always felt that the need to draw a flowchart while designing it shows an inadequate division of your problem. Non-trivial flowcharts indicate convoluted logic that should be avoided at high cost.

On pseudocode

To be honest, I don't use a lot of pseudocode. It is usually faster to just write the code. When I'm done with my code, it's the actual code. In some cases, pseudocode can be helpful, but generally you're working on something very complex, just trying to break the structure of a method or something else. In these cases, I use comments in my IDE to structure the structure so that I get everything right. Then I go in and write the actual code in the comments. This helps me do a couple of things:

  • I can see areas that I have and haven't implemented by reading the comments and seeing obvious gaps in them.
  • If I fill in the correct code I will have comments explaining what I am doing in English. (You'll probably need it if it's so complicated that I have to write pseudocode first).

On flowcharts

The code usually changes so much that flowcharts are only useful for a larger, system-wide architectural design or documentation. In these cases, I'll just put a diagram on a whiteboard to get the gist of it or to show someone else on the team. Unless you really need a flowchart to understand better, you don't really need it to "get" the software right. Nowadays there are many plugins for IDEs that generate flowcharts from the code itself, as well as class diagrams and others (and vice versa). The only real time you need to have a really accurate flowchart is when you can't get the entire architecture and how things work in your head and talk about something visual to spot kinks.

In general, I don't write flowcharts while working on personal projects (since projects aren't very large) and most of the inputs, outputs, and processes are clear.

However, as you begin to work on complex large projects with multiple input sources, flat files, databases, manual interfaces, and so on, flowcharts come in handy.

I would recommend that you write pseudocode and UML diagrams as these tools will help you find better classes, methods, and so on. Sometimes when you write pseudocode, you can find different and more efficient ways to solve a program.

Pseudocode is used to quickly present an idea to those who understand at least the basics of the code. Flowcharts draw pretty pictures so everyone else will understand the same thing.

Flowcharts are often used for documentation purposes because many different people will use this documentation, and flowcharts are easier to follow than pseudocode for non-programmers. In a project you're working on yourself, sticking to pseudocode is fine as it's far more useful and easier to create since all you need is a text editor.

Flowcharts provide a high level of abstraction that you can use, for example, to plan how things should work

If x dies, y wins

They don't have to depend on how you design the program in terms of classes and methods. Pseudocode, on the other hand, offers a lower level of abstraction (although that really depends on it).

if (isdead (s)) ()

Thus, pseudocode can now be translated into an actual program based on the language you are using.

For a game, I would recommend using a flowchart first, then designing the classes and methods, writing pseudocode, and finally turning it into a program

I would take into account the type of code you are writing. If so:

  1. Very iterative / recursive
  2. Branches in a complicated way
  3. Implemented in multiple systems that you want to represent

In the first two cases, the pseudocode is increasingly difficult to read than an overall diagram. On the flip side, code that is mostly linear makes incredibly boring diagrams that actually make the process harder to understand because it blows it up.

In the third case, flowcharts can better represent processes that exceed system boundaries and represent the entire process.

  1. You should use anything that you are comfortable with. However, my impression is that flowcharts are not widely used these days to outline program control. On the one hand, they are typically unstructured compared to pseudocode. It is more common to use class dependency diagrams like UML to describe your architecture on a much higher level. If your application has a state machine, drawing a state machine diagram (flowchart-like) is essential.
  2. I think you are right here. One possibility is to first write your pseudocode as a comment in your source file and insert the actual implementation lines in between.
  3. Again, use whatever you're comfortable with. If you're not sure, try both of them. I assume that your practice will quickly converge on what is most useful to you. Personally, I only find flowcharts useful when trying to unravel a particularly complicated order of execution.

Why write pseudocode when you can write Java? I've found that Java, a good IDE, and Javadoc are the easiest way to catch a programming problem - at least one object-oriented . (And an arcade game should OO.) The language was designed from the ground up for this. It's easy and straightforward. (Maybe too simple for many purposes, but the best I've seen for it.) The hypertext in the Javadoc and via an IDE in the code itself makes a more understandable "diagram" than you could pull off a large sheet of paper. Java code is as simple as any pseudocode and much stricter. And once you've coded it "graphically" and "pseudo", the program will actually run!

You could use a flowchart if you are really confused by if statements and are trying to understand. In trying to understand a loop, look at the effect of counters. If you learn it can help a lot.

It can feel a bit restrictive because you have to put short statements in boxes. And if your program is very linear and your loops and ifs are trivial then I don't see any use for it.

Pseudocode is useful for designing a program. Without the distraction of having to set the syntax correctly and without the boredom that some languages ​​can bring with them. The fact that it is faster to write also makes code redesign easier. And you can be as precise as your mind wants, comfortable to write, requires less mental effort to get it to work (since no or much less debugging), and more ability to focus on the bigger picture and design focus.

So useful for you.

They can also be used to communicate with others.

We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.