So I know of a few people that actually write their algorithms out in plain English (pseudocode) before coding. I'd never done this before, but now that I think about it, it kind of makes sense for organizing complicated algorithms. Do you do this? Does it help? If not, what do you do (if anything) to organize your program before you write it?
I don't write in pseudo code, but I usually do make some sort of a flow chart to guide me along.
If it's non-trivial, I'll use pseudocode first and then include that pseudocode in my documentation if I'm producing any formal documentation for that particular component.
If it's trivial, I just write code in my implementation language and then go through and add comments if anything needs it.
I don't write much pseudo code, but I find that if I can't say what I want to do in plain English, then I don't understand the problem enough to start writing code.
If I know that I need to work on writing the code for another part, but I can think of the general outline of the method or function now, I will write out just enough so that I can remember later my idea on how the method should run. Generally I end up changing it later, so I rarely find it helpful.
I have attempted this but, I find it very difficult to do because, generally there are typically many things which I have not considered until I am forced to write out the algorithm in a strict language. English is just such a good language to lie to yourself in.
I actually found it harmful because I spent time on non-problems, and neglected the real problems that I didn't see until I attempted to write the computer code. In fact, I've written computer code to help organize my thoughts for things I am writing in English.
I have found that drawing pictures and/or taking a geometric approach can be very helpful.
I tend to find myself writing small use cases in notepad using indentation... and after half a dozen lines or so I suddenly realise I'm writing in a style which is essentially Python but with a little less syntax! So I've come to the conclusion that Python is actually pseudo code and a fantastic way to prototype your thoughts in whatever language you're really trying to write in. The best thing about this technique is that you already have a reference you can compare your finished result to in the case of nasty bugs.
I write mainly in Python these days. That is pseudo-code to begin with.
Generally for a function, I will write a nice long header description of what it does (Doxygen formatted, preferably).
If it's complicated enough, I make structure diagrams (old pre-UML pre-OO design), or something like UML sequence or activity diagrams.
For an entire system, of course I start with Class diagrams.
I use comments (both within the method and in the published interface) as pseudo-code.
When implementing an algorithm, the steps I follow in order are:
- Make sure that the API or interface is right. If I can't determine what the correct operations are, or the what data goes in and out, something's wrong.
- Describe each operation in the Javadoc (or equivalent) comments; this usually points out issues with the algorithm or how it is used.
- Write comments in the method or methods as a form of pseudo-code. I do this either before I start writing code or as I am writing the code. This helps me remember what I was thinking before I write it, and documents what I was thinking for future reference.
That would be the dream.
Just write pseudo code and it just works.
In general, not really. If I am at the computer and I'm working on something particularly difficult or tedious I might go through and sketch things out using comments before hand, but they tend to be more of a natural language statement than proper pseudocode. Generally the only time I have ever used proper pseudocode was during a class.
However, it is worth noting that what works for one developer may not work for another developer and some people swear by writing pseudocode before hand.
I'm a huge fan of writing out algorithms in pseudo-code first, just to wrap my head around the algorithm. Its relatively easy (for me) to convert from English to code, so I tend to write more words and less code. I could easily use my pseudo-code as comments for others for sufficiently complex algorithms.
As for the specifics, I usually go with the old paper/pencil, and I indent loops/control statements. Everything else is whatever my mind spits out at the time.
Absolutely... Once, I have something solid in pseudo, I start the "port". Easy to get something complex done in an easy fashion without having language semantics in the way.
My pseudocode, like others above, is basically Python. This is not a statement about my Python expertise, but about how intuitive the language is. My problem-solving skills have always been better than my memory for details like syntax, so it's great to work with a Language that lets me focus on the problem at hand without getting in my way by forcing me to look up syntax so much. Also, one of the benefits of pseudocode vs. other languages is in just writing the logic without stuff like type declarations - and you don't do that in Python anyway, so writing the code is essentially no more work or clutter than pseudocode logic.
I write it in fortran - that's basically pseudocode which pretty much anyone can understand. I can't think of an easier way to write it.
It depends on the algorithm. If it's simple, then I can usually store all the logical paths in my head, if it's complex, then I'll sketch out each step with the relative logic.