in reply to top ten things every Perl hacker should know

  1. All rules are guidelines, including this one;
  2. Always use strict and use warnings;
  3. use constant is your friend;
  4. Regexes are bad, you can often use another way to do it;
  5. While there are many ways to do it, most of them are wrong;
  6. Anyone listing rules for programmers is wrong;
  7. Documentation is for users, comments for developers. You will be a user of your own code, so selfishness compels you to write both;
  8. Tests aren't as necessary as the testing cabal would have you believe;
  9. Tea is the one true source of caffeine;
  10. It's OK to reinvent the wheel sometimes;
  11. There will always be last-minute additions
My second rule is really just a variation on "turn on the fascism options in your compiler; and if the compiler emits warnings that's because your code is broken". My third rule is a special case of general good practice regarding naming conventions.

Replies are listed 'Best First'.
Re: My top ten
by Anonymous Monk on Mar 17, 2006 at 17:49 UTC
    Rewrite for #7

    Users don't read documentation if they have a phone number. Write documentation like you would a mystery novel, and leave clues to your phone number spread out through the documentation. That way, by the time they've figured out your phone number, they've already got their answer and they don't need to phone you.
[reply]
Re: My top ten
by virtualsue (Vicar) on Mar 19, 2006 at 15:53 UTC
    Jolly well done, except for the utter nonsense in point 9. Tea is fine as a supplemental source of caffeine, but nothing more.
[reply]
Re: My top ten
by apotheon (Deacon) on Mar 22, 2006 at 08:32 UTC

    re: "10. It's OK to reinvent the wheel sometimes;"

    I'd say that's generally only true if you can't get at the source for the wheel. Really, wheels should usually be improved rather than reinvented anew. One might also consider whether wheels simply need new tires (wrappers) rather than reinvention, though the outer interface for the wheel might need to be redesigned to accept your new tire design.

    There are exceptions to every rule, including the "use strict and warnings" rule — particularly in Perl culture — but I don't think that invalidates the rule particularly.

    print substr("Just another Perl hacker", 0, -2);
    		 - apotheon
    CopyWrite Chad Perrin

[reply]
      I strongly disagree.

      Just because someone else has written a piece of crap, doesn't mean that I have to use it.

      In fact I'd say that one of the critical programming skills that few develop is being able to properly decide whether to reuse or ignore a particular wheel. It isn't an easy decision. And it certainly isn't as simple as saying, Always do _____.

      The advice to always reuse wheels is good advice to give beginners exactly because they are beginners. Wheels that they're likely to hear about from experienced programmers are always going to be better than what they can write for themselves. But good programmers have a harder decision to make. Because if you actually are good, you probably can create better wheels than a lot that are in use out there. The question then becomes whether it is worth the time and energy to do so. Usually it is not, but sometimes it clearly is.

[reply]

        Someone writing a "piece of crap" hasn't really invented a wheel, though — he's only invented a "piece of crap". If someone presented a 4x12 rectangle on an axle, I wouldn't call it an invented wheel.

        I think, at this point, we're really not disagreeing in principle — only in phrasing.

        print substr("Just another Perl hacker", 0, -2);
        		 - apotheon
        CopyWrite Chad Perrin

[reply]
      Sometimes the guts of a module are so tied to the interface that to adapt it means to rewrite it anyway, in which case it's usually quicker to just write a new module than it would be to pick the old one apart and then hack it up beyond recognition. A good example is GD::Graph, which I am very seriously considering re-writing to add some features and fix others.
[reply]

In Section Meditations