+24  Q: 

Do you pseudo-code?

Do you use pseudo-code to help you program? Does it help you write your programs faster with less bug-prone code or does it simply waste time?

Should it be standard practice to declare what you're going to program before being allowed to get your hands dirty writing? (See Literate Programming)

Please write your opinions and the benefits/downsides as I'm thinking up a policy here.

+2  A: 

I use psudo code to plan stuff on paper, or occasionally I'll write the psudo code as comments and then code up the code bit by bit...

I don't know if it slows me down, I only do it sometimes, however some languages are almost as readable as psuedo code, I once heard Python described as executable psuedocode...

Omar Kooheji
I think even for the languages that are like pseudo-code, sometimes its best to leave comments, describing WHAT you're trying to do rather than HOW you're doing it!
+2  A: 

We don't psuedo-code as much as outline. An outline of a particular process/group of processes is a great thing to have both from a documentation standpoint and from a template to work from standpoint. It sorta goes along with programming to interfaces in a lot of languages. Write your interfaces, and then write the code for those.

I like to include an outline though at the top of all of my "scripts" (single contained processes) and then also with my developer documentation for all of my applications. But as far as writing actual psuedo-code for the entire app, no, I would feel that would be a waste of time. But I would also think that would have a lot to do with the language as well and how "readable" it is.

Ryan Guill
+13  A: 

Generally the only time I actually psuedocode is when I'm working out an algorithm on paper during the planning stages of a piece of work. The only other times I will use psuedocode is when I'm trying to explain an algorithm or a work-flow of some sort to a coworker.

+1  A: 

I don't use pseudocode, but I have adopted the habit of writing the comments first for complicated functions, then filling the actual code in later.

You'd call exactly that Pseudo-code! See
+8  A: 

I use pseudocode if I'm working on a complex piece of code that I can't really visualize all at once in my head. However, I don't think it makes my code less bug-prone.

Writing pseudocode is like creating sequence diagrams. It can be useful, but it's not necessarily an essential part of the development process. It helps some developers visualize their programs better and allows them to share their plans with other developers for comments.

I personally wouldn't make it mandatory. If bugs are a concern, I would rather make unit tests mandatory.

Quite conclusive.
+3  A: 

Hell No! :) ... I just write short algorithms, max 10(approx) lines (yeah! call 'em pseudo-code). This helps me to put my ideas out in a concrete form, so that I'm clear about the solution I'm about to code.

But I just don't jump to write algorithm/pseudo-code for everything I code. I do it when I'm a bit confused, or not able to think about it all in mind.

That said; I do create a rough plan on paper with classes/function/objects and other mumbo-jumbo required for my solution, with a short(long enough) note to describe what each of the entity has to do.

The above can be an iterative process. Putting more details as required. In plan or in the algo/pseudo-code.

+1  A: 

That depends on your definition of pseudocode. If, by "pseudocode," you mean the classic definition of writing out plain English sentences that describe the algorithm and which could later be used as documentation comments, then, no, I don't pseudocode.

I am, however, a whiteboard fanatic. If I could replace my every inch of my walls with whiteboards, I would. The ability to work out an algorithm, a database schema, or a class design in whiteboard markers, with complete freedom (or abandon) with the knowledge that I'll never hose the source code while I'm doing it is a godsend. I can rework that design over and over and over again until I'm happy with it, and only then do I start putting it into the code base.

Pseudocode? No. It's too tempting to just start hammering out code that way, and that's far too likely to become the finished product. And more often than not, it's neither what I intended nor what the customer desired.

Mike Hofer
Hmmm.. In other words, you prefer drawing to writing while designing or planning!
Not always. I can WRITE an algorithm in whiteboard marker, erase it, and do it again without worrying about hosing the code base. Sure, I can't compile the whiteboard ;-) but I can see an overall design and work with it.
Mike Hofer
At the last place I worked, we had small conference offices that had whiteboard material for the walls. It is possible!
Mark Ransom
+2  A: 

I only use pseudocode when I need to think about something and/or code carefully. It's a great way to work out an algorithm.

+3  A: 

yes i write in python

im sorry, this was downvoted because?
Probably because you didn't explain your answer, and it seems flippant. While Python isn't pseudo-code, I think it's the closest you can come in a practical language.
Mark Ransom
sorry, this question is rather "who cares?" imo
When you write a "who cares" answer, expect to be downvoted. That's just how the site works. The golden rule is to try to be helpful.
Mark Ransom
I actually don't get the up votes on this one. It isn't that humorous now is it?
David Walschots
+41  A: 

Quite often, I code what I want my process to do in very clear, high level English, as comments in my code. Then, below each comment, I actually implement that statement.

For bonus points, I would say the closer your higher level concepts are to your English code, the better designed and better encapsulated your process is. It implies a handful of things:

  1. You are fulfilling the expected business objective.
  2. Your implementation details are sufficiently hidden from and do not obscure the business objectives.
  3. Your code, with relation do the business domain, is self-documenting, and lends itself for non-programmers or new programmers to quickly understand the purpose of your code.
  4. It protects your future-self. Often times you forget. Everyone forgets. But the code repository, like a good elephant, never forgets. The code will be as clear as day, and you will thank yourself, and minimize the downtime of having to re-learn your framework and your objectives.
  5. Insurance. Having the objectives written down, logged, and committed provides you insurance against undocumented changes in the future. If someone tries to pull a fast one on you, you can say, nope, here, this is the contract we decided on. If you'd like to change it, let's first redo the outline and block out some time to change the code, etc...
Mark Canlas
Thorough! Well formulated and good points.
That from Code complete, isn't?
Its Code Complete speaking :)
Bravo! How it should be, especially for complicated tasks
Jas Panesar
+1  A: 

nope, i use a mindmap. if i need to visualize something and break it down i'll use pseudo code. otherwise i'll just write code unless i am away from a pc.

+1  A: 

Should it be standard practice to declare what you're going to program before being allowed to get your hands dirty writing?

Yes, but by writing unit tests (and therefore declaring it formally), I'd say.

Fabian Steeg
I disagree. Writing unit tests and writing pseudo-code are two different things. When you write a unit test, you're essentially planning how you want the objects to be used, and how you expect them to work from an external point of view. Pseudocoding is *internal.*
Mike Hofer

Yes. Usually to show how I would go about solving a problem to another dev. Best done on the back of envelopes, napkins, receipts or some other disposable paper. (I have scanned napkins with valuable pseudo code on them!)

+1  A: 

I find it helps a huge amount (while learning the model, the system or the language, so basically all the time :-) to model the problem in a couple of different languages, or at least read up on how other people have solved it in other languages. You'll find this will give a much clearer idea of the actual problem (versus the definition on paper), along with a better idea of the strengths and weaknesses of various approaches.

So, yeah, I do the odd pseudo-code, especially when I find a problem that doesn't spring easily to mind in the more syntactically simple languages (Python is ideal for this sort of thing).

+1  A: 

I always pseudo code. On most things I do it at a high level. I basically outline what I need to accomplish. I currently use MLO (, which I use to refine and organize my thoughts. Most of the detail lines end up being a function or method. I also outline in more detail the more complicated functions/methods. The outline eventually becomes comments in my code.

I have always done it this way. The only difference is what I use to outline. I started with pencil and paper, moved to a text editor (Borland's Turbo Edit), then BBO (Brown Bag Outliner), Ecco, and finally MLO.

I don't have any strong feelings about going straight to code. There is a lot of experimentation that I do, that is straight to code. If a straight to code project of mine ends up becoming more, it will go through a refactoring/reorganization that will cause me to outline it's functionality. In those cases I still end up outlining the program in pseudo code after the fact. Usually the straight to code pieces end up being a small part of a bigger project and end up fitting in somewhere on that bigger project's outline.

It has worked for me for 28+ years. I usually find that it also helps me break down the more complicated problems into their manageable pieces, even ones that aren't that clear to me at first glance. I find that outlining in pseudo code helps clarify what needs to be done and actually helps me come up with a better solution then the one that I originally started to outline.

+3  A: 


I find that psuedo-code helps strip down some of the complexity in large programs. You have a clearer, concise idea of what you are trying to program as well.

The drawback is that it does take a bit more time in the beginning if you psuedo-code but personally I think the investment is worth it. In my experience, psuedo-coding gives me a way to think through the problem I am trying to solve, protecting against possible errors in logic down the stretch.

I would be careful with making pseudo-coding mandatory in your development group. Developers all have different ways of coding and what practices work for some may not work for all. I definitely would not use it for documenting purposes. There are better tools / frameworks for that, such as mind maps, TDD, RSpec etc.

Hope that helps,



pseudo coding is a very good habit provided that we dont over do it... Keep it simple and straight forward, i put pseudo codes and then turn them into my code comments.

+1  A: 

For simpler logic, I never write pseudo code. When I think some business scenario implementation which appears complicated when I visualize, and appears simple when I put it on paper. Then I check for the possible future use of this, I take out the invariable part out and then code.

Most of the times, It reduces bugs in my case and even saves time. Since, the rework is avoided.


I use pseudo code when solving some complex problem. And we also encourage our developers to do so. It helps in better understanding the problem at hand, helps figuring out corner cases, many what-if scenarios etc.

Tanveer Badar
+4  A: 

When the code is a little bit complicated, I will actually write the pseudo code out as commens as I think of what needs to be done.

Something like this:

// Get list of files
// Iterate through them
// select the file we're looking for
// return it to the user

Obviously, that's a trivial example but it illustrates what I do in that I go through the thought process of each step.

I find it helps to break it down without having to worry about the specifics and also, those particular sections are often function calls.



I don't really pseudo code, but I do often attempt to define some of the interface before I just jump in. Oftentimes, however, I find that it's not possible to know beforehand exactly what you need until you actually sit down and write the real code. The design and implementation tends to reveal itself naturally as I write more and more code, and discover constraints and needs of the system that I didn't think about before.

I suppose you could do the same thing in pseudo-code. I just prefer not to repeat myself and just write the real code the first time.

var answer = true;
+1  A: 
+1  A: 

For anyone who values pseudocode but may have been frustrated by the lack of effective tool support you may find the following tool of interest: Code Rocket ( )

It provides a dedicated pseudocode editor which is embedded inside Visual Studio and Eclipse and provides forward and reverse engineering of pseudocode to/from code


Have you ever noticed how small children talk about what they are going to do? They verbalize their actions because it helps them understand / cope with the complexity of the world with which they interact.

Comments are the programmer's way of coping with complexity.

However, as children grow, and they have a deep understanding of their environment, the need to verbalize to understand disappears.

As programmers understand the domain, the language they use, and some other core concepts, the need to comment also diminishes.

Esteban Araya