in reply to Rules of Proper Perl Style

Rule 1, don't call them rules. =) Guidelines is a much better term. There are times and places to violate all of these. Here are the guidelines I try and live by (usually failing miserably).

Hidden behavoir like non-obvious return values can eat you alive. I try and avoid subs that both modify a parameter handed to them and return a real value. I try to use return $blah; so that people don't add a print at the end of my sub and suddenly it ALWAYS returns a "1". =)

--
$you = new YOU;
honk() if $you->love(perl)

Replies are listed 'Best First'.
Re: Re: Rules of Proper Perl Style
by McD (Chaplain) on Feb 13, 2001 at 03:32 UTC
    extremely writes:

    Rule 1, don't call them rules. =) Guidelines is a much better term.

    Amen! TMTOWTDI, for just about any vaule of "It."

    I'll add a plug for my favorite short read on writing literate Perl here. Some of you might recognize the author.
    :-)

    And as for adding guidelines:

    • Comment your data structures,
    • And use good, long, descriptive variable names.

    Bonus points for anyone who can remember who it was that said "show me your data structures, and I don't need to see your algorithms..." or something like that.

    Peace,
    -McD

      That'd be Fred Brooks. The exact quote is
      "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
      Kinda hard to believe now, but back in the days when we had to shovel coal to power our mammoth steam-belching, card fed computers, procedural code was the order of the day. The idea of organizing code around "data structures" was a strange one.
      Frederick P. Brooks's -- The Mythical Man-Month
      "Show me your flowcharts and conceal your tables, and I'll continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
        Sorry dws, the masked stranger is right. This is from the last section of chapter 9. The full paragraph is:
        Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious.
      Oddly enought, the "short read on writing literate Perl here", mentioned at the start of this thread, includes the following:

           "Rob Pike says: `Data dominates. If you've chosen the right
            data structures and organized things well, the algorithms
            will almost always be self-evident.  Data structures, not
            algorithms, are central to programming. (See Brooks p. 102.)'"

      We all seem to be dipping our toes in the same stream :-)

      p
      update: That "toes in stream" was the best I could come up with at that moment.
      shoulda/coulda been: "Which only goes to prove the point."