Re: Re: best practice

[dragonchild]

I disagree with not writing Perl pseudocode. (Or, rather, I would if I ever wrote pseudocode.) Just because Perl is a higher-level language than C doesn't mean that writing in it frees you from good design practices.

It ends up that most of the uses people put Perl to are simple enough that pseudo-code isn't necessary. However, I worked on a project that was a full-fledged system. We wrote pseudo-code on whiteboards and the like a number of times. Whenever I didn't write pseudo-code, I generally regretted it. (However, I still didn't write pseudo-code. I'm great on theory, lazy in practice. It's also why I'm great with rewrites. *grins*)

Now, pseudo-code takes a lot of forms. For example, if you're writing a CGI script, the pseudo-code has been created for you - it's called CGI.pm and you should use it. Your design document is the mockup of the page you want to create. (You do create mockups of your website beforehand, right?)

Another example would be the brainstorming you do with a coworker that gives you the idea in mind. You then go and write a prototype. You test that, adding onto it, and end up with your development module. You bang on that some more and end up with v0.1 - that's a type of pseudo-code we call "prototyping" and "iterative development".

Now, I'm not saying that doing PDL, or the like, is a bad thing. In fact, in languages that require you to do more work (like C++ or Fortran), it's necessary if you're doing anything with any sort of complexity.

To achieve a similar level of design-need in Perl, you probably have a much higher level of output-need. Which boils down to:

To achieve 'A' in C, you need pseudo-code. To achieve 'A' in Perl, you might need pseudo-code, but it's probably a good idea.

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

Vote paco for President!