Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: best practice

by Aighearach
on Aug 27, 2001 at 18:10 UTC ( #108126=note: print w/ replies, xml ) Need Help??


in reply to best practice

I also recommend The Pragmatic Programmer.

But another thing I recommend is, don't write pseudocode for Perl. In a low level language like C that is needed, but in a high level language it is less needed. I prefer another system of prototyping: the rough draft. Or, as the saying goes, (anybody know who I'm quoting?) "plan to throw one away. You will, anyways."

UPDATE: To clarify my position on design documents, while I don't think pseudocode is particularly valuable in Perl, I do think charts are valuable, and I do recommend using charts to determine the best data structures.
--
Snazzy tagline here


Comment on Re: best practice
Re: Re: best practice
by dragonchild (Archbishop) on Aug 27, 2001 at 18:21 UTC
    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!

      Just because Perl is a higher-level language than C doesn't mean that writing in it frees you from good design practices.
      Of course. I'm not suggesting abondoning good design practices. I'm suggesting a different set of design practices that is popular amoung some groups of Perl programmers.
      You do create mockups of your website beforehand, right?
      No, I use a template system so that design and code are seperate, and design can be changed on the fly. Perhaps the web designers resposible for the look and feel do mockups; I wouldn't know what good web design practices are, I'm just a programmer.
      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.
      No, that's called code reuse, and yes it is a wonderful thing.
      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 psuedo-code we call "prototyping" and "iterative development".
      No, that's a rough draft or prototype, not pseudocode. By definition, pseudocode is not real code and cannot be executed. Not everything that is part of the design phase is pseudocode.
      --
      Snazzy tagline here
      You wouldn't happen to have a blob of pseudocode lying about the place that you could paste in to give a flavour of how you write it? Perhaps with a corresponding finished snippet? I sort of have an idea of what pseudocode is, but I'd be grateful for pointers about how much detail others find it useful to go into, etc.

      George Sherston
        I personally don't write pseudocode, primarily because the type of projects I work right now on tend to not need it. However, according to
          Code Complete
        , pseudocode should adequately describe the functioning of the routine in detail enough to implement it in any language, yet not go into so much detail that it's obvious what language it was designed for.

        For example, you wouldn't say "Increment $i by 1.", because you've limited what languages you can write this pseudo-code in. Instead, you'd say "Increment the Bank Record Number by 1.". Or, even better, you would say "Go to the next Bank Record."

        Say you were taking money out of a ATM. (This is a common example in the books.) It might look something like:

        Put your card into the ATM Input your PIN# when requested Input desired amount of money Wait for money to arrive Take money and card and receipt
        Now, you can take those five lines and convert them into running code in any language, given a set of functions that can interface an ATM. I haven't limited your choice of language.

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

        Vote paco for President!

Re: Re: best practice
by George_Sherston (Vicar) on Aug 27, 2001 at 18:38 UTC
    If you've got one handy I'd be very interested to see an example of a rough draft (perhaps versus a finished script) to get an idea of how much detail you get into at that stage.

    George Sherston
      A rough draft would contain a lot of the following type of lines:
      #GGG Add error-checking here. #GGG When in production, this line changes to $foo=2;
      'GGG' is just a character string that allows me to search for it and find all my to-do notes.

      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
      When I said "throw one away," I really meant it. :) I don't have any because I invariably delete them. In fact, I don't even bother putting them into cvs.

      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

Re: Re: best practice
by clemburg (Curate) on Aug 28, 2001 at 13:57 UTC

    Or, as the saying goes, (anybody know who I'm quoting?) "plan to throw one away. You will, anyways."

    You are quoting Fred Brooks, from "The Mythical Man Month".

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://108126]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2014-08-30 10:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls