Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

  (email not shown publicly)

I work for MessageLabs [] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Tuesday September 17, 2002
12:20 PM

Programming without variables

[ #7778 ]

In, Simon muses about programming without variables, and how everything looks nice and clean.

I've been there too. Except now I err on the side of using variables. Why? Because my personal debugging technique is to dump stuff to STDERR and examine it. I never ever ever use the perl debugger. So in order to be able to insert random debugging events here and there I generally have to use variables.

At least that's my excuse ;-)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  •     shift->TicketObj->Subject =~ /^Perforce file (.*#\d+) for review/;
        print SSH $1, "\n";
    Ugh. What happens when it doesn't match? Apparently Simon has not been reading MJD's Program Repair Shop closely enough.

    Didn't Simon write a Beginner's Perl Book? Maybe I should distrust more and more of that book.

    • Randal L. Schwartz
    • Stonehenge
    • Ugh. What happens when it doesn't match?

      Bzzt! That can't happen.

      Notice the sub called IsApplicable? That's tested before the Process sub is called.

      But I suppose you couldn't pass up an excuse to trash a competing book.

      • There's no such thing as "that can't happen", and no excuse for at least adding "|| die" to that statement so that at least if the match didn't happen, you wouldn't be using a stale $1.


        • Randal L. Schwartz
        • Stonehenge
        • or even an assert_defined($1) if you're using Carp::Assert::More [].

          I have to agree with Randal, and I'm surprised that Simon would say "that can't happen" [].



          • or even an assert_defined($1)
            No, that's insufficient. If the match fails, you get the previous value of $1, which is why this is such an insidious bad idiom, and even a potential security hole.

            You must test the result of the match to see if it matched or not.

            • Randal L. Schwartz
            • Stonehenge
            • True enough. And y'know, I was just thinking about this last night while I was reading Friedl's 2nd edition of Mastering Regular Expressions, too...


        • Forget the || die. Simon could have written just as easily:

          print SSH $1 if $foo =~ /.../;

          And, for those of you who might think Randal is being harsh, well, try pair programming with him. You guys have it easy. He holds Stonehenge instructors to an even higher, higher standard (and I thank him for that).

          We all write bad code. It's how we act when someone points it out that matters. :)
      • (Sorry, this should have gone in the other post.)

        And, it's not so much that you have a "competing" book, except that I mentioned that because I hold anyone who teaches (or writes for) beginners on a regular basis to a higher standard.

        Since you have made yourself one of those people, you get judged more critically by me. You have a higher responsibility to write more robust and cleaner code, and counter-examples will be pointed out in that context because it discredits your consistency of mission.

        At l

        • Randal L. Schwartz
        • Stonehenge
        • Say, with this code (I know it could be written better, but for the sake of the example ...)

          if (m/\w+\d+\w+/) {
              print $1, "\n";

          Would you put a double extra check on the s///?

          Then, can't you reasonably say "it won't fail!"?

          I think you can, sometimes. :-)

          (and as someone else pointed out, Simon could easily rewrite the code to do the check without an extra variable; I agree that the calls to open, print to and close SSH should have error checking though).

          -- ask bjoern hansen [], !try; do();

          • "Then, can't you reasonably say "it won't fail!"?"

            Not right now. But after three changes to the first regexp, and the second regexp being pushed down a few lines (so it´s not in proximity to the first), it´s not that obvious anymore, right?

            It´s far fetched (and maybe not worth fuzzing about), but not _that_ far fetched :)