in reply to Parsing the command line: manual or module?

The risks are the same as any other time you avoid code reuse. Just off the top of the head:

  • Comment on Re: Parsing the command line: manual or module?

Replies are listed 'Best First'.
Re^2: Parsing the command line: manual or module?
by doom (Deacon) on Aug 17, 2006 at 18:39 UTC
    I would add:
    • Getopt::Long is the standard in the perl community, and when you hire new perl programmers they'll expect to see something like it in use (if they're any good).

    Actually, this isn't a bad interview question to ask a prospective employer: if they're writing command-line perl scripts and not using a Getopt::* module, they probably have other problems as well.

Re^2: Parsing the command line: manual or module?
by apotheon (Deacon) on Aug 17, 2006 at 19:42 UTC

    Your third point is sort of an outgrowth of your second (here's hoping you don't edit that unordered list in such a way that this sentence becomes meaningless). It's a darned good point: drifting code is one of the biggest disadvantages of DRY principle violation. This is also the major opportunity for actual bugs to be introduced due to the by-hand specification of command line option parsing in every single program individually.

    Plus, y'know, a good programmer should be lazy enough about stuff like this to want to do it "right" in the first place, since it's less work to use someone else's command line option parsing module than to write your own code every time.

    Of course, Getopt::Std is simpler to use, so that might end up being the really lazy answer.

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