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.
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...
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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!)
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).
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 (mylifeorganized.net), 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.
Yes.
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,
Ben
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.
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.
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.
G-Man
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.
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 ( http://www.getcoderocket.com )
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.