#GGG Add error-checking here.

#GGG When in production, this line changes to $foo=2;
[download]

Also, a rough draft doesn't have good comments. It doesn't have a lot of error-checking (though you should build it in as you go.) It probably also isn't factored very well.

What a rough draft does have is good variable names. Changing variable names in mid-stream is a pain in the ass. Get your names right. If you can't name a variable neatly and succinctly, that's a clue that you don't understand what you're doing.

(The above paragraph goes doubly for function names.)

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!

Well, if that was what I meant by a rough draft, I wouldn't be recommending it as an alternative to pseudocode, but rather as an addition.
--
Snazzy tagline here

The idea isn't that I'm cutting corners on the rough draft. The idea is, rather, that in a language like Perl where there are many ways to approach a problem, you don't know what the best approach is until you've mucked about in the problem domain a bit. That's the problem with pseudocode; your pseudocode has to contain a high level algorithm, but you often don't know yet which algorithm to use. So my first draft might be procederal. My next draft might be OO. I might switch to a recursive algorithm, or decide to use Tie::RefHash to move all my filehandles into hash keys, storing related data or objects in the value. Usually, I don't know this until I've written some code.

I can't imagine the pseudocode for procedural and OO approaches being the same; if it's that high level, it's mostly useless anyways.

And if your first algorithm guess is always correct... well, only mortals would need pseudocode anyway.
--
Snazzy tagline here