10

I'm a student working with various techniques of programming, and I've come across pseudocode and flowchart. I know that these are both used in order to think through the problem before actually programming, but I have a few questions with this.

  1. When would I use pseudocode to plan out and when would I use flowcharts? Or is it better to do both before actually programming. Particularly for a small arcade sort of game in JAVA since that is my next project.
  2. I've noticed that pseudocode is very similar to the actual code rather than flowcharts. Would this make pseudocoding better because you essentially copy/paste the pseudocode into your program (of course, you have to change it to fit the language. I understand that part).
  3. Is it practical to use both of these while programming? Particularly the same game mentioned earlier. Thanks.
kullalok
  • 1,075
  • 3
  • 9
  • 10
  • Obviously, you would not use flowcharts where you've got no flow - i.e., for almost all the declarative entities. – SK-logic Jun 28 '12 at 17:55
  • 1
    I can't actually remember the last time I saw a coding flowchart. Class and data-flow diagrams, use-case diagrams, yes. But not flowcharts. Maybe they are more prevalent in game development. – Robert Harvey Jun 28 '12 at 18:08
  • @RobertHarvey, FSM diagrams (which are, essentially, flowcharts) are used quite often in the hardware design – SK-logic Jun 28 '12 at 19:19

9 Answers9

7

Flowcharts and pseudocode often have the same level of expressiveness, but differ in linearization. Pseudocode is linear (i.e. a sequence of lines with instructions), a flowchart is not. Therefore, flowcharts are a higher abstraction level, used before writing pseudocode or for documentation.

Flowcharts have, in my opinion, two strong advantages over pseudocode: Firstly, they are graphical. Many non-technical people have a strong fear of structured text, but not of graphical descriptions, so flowcharts will sit much nicer with them. Secondly, flowcharts are much better at expressing meta-considerations such as showing the main line of execution as opposed to branches.

Your questions in detail:

  1. For a really complicated problem, you would use flowcharts first, then pseudocode. Both are optional when you feel secure enough.
  2. Yes, pseudocode has the advantage of being mergeable with real code. Steve McConnell, for example, strongly recommends writing methods in pseudocode first and then leaving the pseudocode in the code as comments.
  3. I always felt that the need to draw a flowchart during design shows insufficient partition of your problem. Non-trivial flowcharts indicate convoluted logic, which should be avoided at great costs.
thiton
  • 5,348
  • 1
  • 27
  • 26
  • 1
    Flow charts are also great way s to make sure that every decision point defines the actions for the less common path(s) as well as the most common one. This helps make sure you will know what to do when the approval is denied or the order is cancelled! There are often more bugs in the edge cases because people forget to do them or do them in a rush during QA when testing finds them. – HLGEM Jun 28 '12 at 20:44
3

On Pseudo Code

To be honest, I don't use pseudocode much. Typically it's faster to just write the code, so that when I'm done with my code, it's actual code. There are some cases when pseudo code may be helpful, but you're generally working on something very complex and just trying to break down the structure of a method or something. In those cases, I use comments in my IDE to lay out the structure until I get things right. Then, I go in and write the actual code in the comments. This helps me do a few things:

  • I can see areas I have and haven't implemented by reading the comments and seeing obvious gaps in them.
  • When I fill in the real code, I have comments explaining in English what I'm doing. (They'll probably need it if it's so complicated that I need to write pseudo code first).

On Flowcharts

Code typically changes so much that flowcharts aren't helpful except for larger, more system-wide architecture design or documentation. In those cases I'll just whiteboard a diagram to get the gist of things or to show to someone else on the team. Unless you really need a flowchart to help you understand, then you don't really need them to "do" software right. Nowadays, there are lots of plugins for IDEs that will generate flowcharts from the code itself, as well as class diagrams and others (and vice versa`). The only real time you'd need to do a seriously accurate flowchart is if you can't keep the whole architecture and how things work in your head at once and need to talk through something visual to catch kinks.

Ryan Hayes
  • 20,139
  • 4
  • 68
  • 116
0

Generally i don't write Flowcharts while i am working on Personal projects (as projects are not much big) and most of the inputs, outputs and processes are clear.

but as you will start working on complex big projects with different input sources flat files, databases, manual interfaces etc flowcharts are handy.

I would recommend you writing Pseudo code and UML digrams as these tools will help you to come up with better classes, methods etc. Sometimes while writing pseudo code you will find different and more efficient ways to solve a program.

CodeCracker
  • 41
  • 1
  • 5
0

Pseudo code is for quickly representing an idea to those that understand at least the basics of code. Flowcharts are fr drawing pretty pictures for everyone else to understand the same thing.

Flow charts are often used for documentation purposes because many different people use that documentation and flowcharts are easier to follow than pseudo code for non programmers. In a project you are working on for yourself sticking with pseudo code is fine as its far more useful and much easier to create since a text editor is all that you need.

Ryathal
  • 13,317
  • 1
  • 33
  • 48
0

Flowcharts are a high level of abstraction they let you plan how things should proceed, For example

if x dies y wins

They don't need to depend on how you are designing the program in terms of classes and methods, pseudo code on the other hand provide a lower level of abstraction (though it really depends)

if(isdead(s)) y.win()

thus pseudo code can now be translated into actual program based on the language you are using.

For a game I would recommend using a flowchart first, then design the classes and methods, write pseudo code and finally convert that into a program

nischayn22
  • 734
  • 1
  • 7
  • 20
0

I would consider the nature of the code you are writing. If it is:

  1. Highly iterative/recursive
  2. Branches in complicated ways
  3. Implemented in several systems, which you want to represent

In the first two cases, pseudocode becomes progressively harder to read than a big picture diagram. On the other hand, code that is mostly linear makes incredibly boring diagrams that actually make the process harder to understand because of how much it blows it up.

For the third case, flowcharts are better at representing processes that cross system boundaries and represent the entire process.

Chris Pitman
  • 3,426
  • 1
  • 18
  • 21
0
  1. You should use whatever you feel comfortable with. That said, my impression is that flowcharts are not heavily used to sketch out program control these days; for one thing, they are typically unstructured, compared to pseudocode. It is more common to use class-dependency diagrams like UML, to describe your architecture at a much higher level. Also, if your application has a state machine, drawing a (flowchart-like) state machine diagram is essential.
  2. I think you are correct here. One way to work is to write out your pseudocode as comments in your source file to start with, and insert the actual implementation lines among them.
  3. Again, use whatever you feel comfortable with. If you're not sure, try them both out; I expect your practice will quickly converge on whatever is most useful to you. I personally don't find flowcharts useful unless I'm trying to untangle a particularly complicated execution order.
comingstorm
  • 2,727
  • 1
  • 13
  • 14
0

Why write pseudo code when you can write Java? I've found Java, a good IDE, and Javadoc are the easiest way to grasp a programming problem--at least an Object Oriented one. (And an arcade game ought to be OO.) The language was designed from the ground up for this. Its simple and straightforward. (Too simple for many purposes, perhaps, but the best thing I've seen for this.) The hypertext in the Javadoc and, via an IDE, in the code itself make for a more understandable "diagram" than you could draw on even a large sheet of paper. Java code is as simple as any pseudo code and a good deal more rigorous. And once you've got it "diagrammed" and "pseudo" coded, the program will actually run!

RalphChapin
  • 3,270
  • 1
  • 14
  • 16
  • 1
    java and others can be long winded."public static void main.." or "system.out.println" or long identifiers with camelback notation, long winded there.n then exceptions that have 2b caught..And calling any libraries can be long winded.I remember 10 years ago opening a file. something like new BufferedReader(new InputStreamReader(System.in)); apparently easier now http://www.mkyong.com/java/how-to-write-to-file-in-java-bufferedwriter-example/ But really any library you call could be long winded, not like pseudocode which can be as concise as you can imagine – barlop Nov 05 '13 at 21:33
  • also in java or any language, you hit on errors on compilation. none of that with pseudocode. you get to focus on design with no distraction. Comments on pseudocode can be much more brief as pseudocode is clearer to the mind as it's from the mind. You're not limited by thinking in only one language, and you might see ah i'll use this other language. It's quicker and less painful to write(no compilations needed - even the very fluent get compilation errors) and so less time to write makes it easier to redesign. – barlop Nov 05 '13 at 21:37
  • @barlop: It works for me, but it may not work for everyone. I leave a lot of code ("BufferedReader", for instance) out of my classes until I need it or need to know if I can make it work. Even when I have it, it's stashed nicely out of the way in classes I don't need to look at when considering overall design. Compiler errors are easily fixed and can prevent major design flaws, such as using the wrong class at a point where you can't even _get_ an instance of the right class. I admit, I _have_ "designed" software this way that could _only_ be written in Java, but the OP _is_ using Java. – RalphChapin Nov 06 '13 at 00:25
  • so say you want to open a file, do you see how pseudocode of openfile("c:\blah\file") is shorter than the java to do it? or that print "dfdfd" is shorter than the java to do it? I've never done(yet) pages of pseudocode and multiple classes. partly 'cos I haven't written big programs in ages b)partly 'cos I don't think I would, I think i'd write some pseudocode then get it implemented. Any other pseudocode if there is any, would be higher level. I might have a list of all classes and methods including constructors. So I know what classes are what and that I can get an instance of it.. – barlop Nov 06 '13 at 10:33
  • so I wouldn't be in a situation of using the wrong class but anyhow, if it's my program, i'd have written down in my notes what class is what.. classes are pretty high level. i'd have a note on that if I can't remember it. And pseudocode is all about what one means, so if you meant to make an instance of class blah and you wrote bleh, then it's just a writing typo but it doesn't hinder your design. (if you're writing for yourself 'cos you know what you mean, and you used it like a blah). – barlop Nov 06 '13 at 10:35
0

You could use a flowchart if you're getting really confused by if statements and you're trying to understand that. Or if you're trying to understand a loop, see the effect of counters. If you're learning it can help a lot.

It can feel a bit restrictive 'cos you have to put brief statements into boxes. And if your program is very linear and your loops and ifs are trivial, then I see no use for it.

Pseudocode is useful for designing a program.without the distraction of having to get the syntax right, and without the long-windedness that some languages can involve. The fact that it's quicker to write also makes it easier to redesign code. And you can be as concise as your mind desires, it's pleasant to write, requires less mental effort on getting it to work (as no or much less debugging), and more ability to focus on the big picture and design.

So, useful for yourself.

They can also be used to communicating to others.

barlop
  • 101
  • 3