Stories
Slash Boxes
Comments
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 ]

KM (4)

KM
  (email not shown publicly)
AOL IM: perlguy13 (Add Buddy, Send Message)

I wrote a book, maybe you will buy it. Writing CGI Applications with Perl [perlcgi-book.com]

Journal of KM (4)

Wednesday January 29, 2003
12:09 PM

labels

[ #10266 ]
Many of my co-workers do things like this.. EVERYWHERE:

SWITCH: {
   if (foo) {
      do something
      last SWITCH;
   }

   if (bar) {
      do something
      last SWITCH;
   }

   if (baz) {
      do something
      last SWITCH;
   }

      last SWITCH;
}

And, I tell them over and over that this really isn't what labels are for. I even tell them that it causes Perl to needlessly keep track of more things, and show them some examples of when a label may make better sense, like:

FOO: for my $foo (@bar) {
   blah blah
   BAR: for my $bar (@baz) {
      if (something) {
         next FOO;
      }else{
         next BAR;
      }
}

or

FOO: { something }
BAR: { something }
BAZ: { something }

if (foo) {
   goto FOO;
} elsif (bar) {
   goto BAR;
} else {
   goto BAZ;
}

Basically, using them in a way which isn't simply adding a useless label around a simple block of conditionals.

Am I crazy in my advice here? Is there any other way I could convince people that this just isn't the best programming practice and not just a pet peeve? This is all througout the codebase. A script may have 5 of these (or more) and use multiple modules which also have many of them, etc.. HELP!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Slice their ethernet cable. Problem solved. :)
    --

    -biz-

  • No, I wouldn't use a switch-like construct there. What's the point of a label when there's a much cleaner solution? I would probably use a dispatch table like the following:

    my %dispatch = (
      foo => \&foo,
      bar => \&bar,
      baz => \&baz
    );

    #later

    if ( exists $dispatch{$function} ) {
      $dispatch{function}->(@args);
    }
    else {
      die "No such function ($function)";
    }

    I don't know, maybe it's just me, but that seems much cleaner and

    • Well, I use dispatch tables. But it hasn't caught on with most co-workers. Anyways, the point is trying to get a good way to explain to these people that the way they use labels is wrong. The examples I showed, although not the best way to do things (aside the nested loop), are more 'valid' ways to use labels. Dispatch tables are better than 'goto LABEL', but I show that as an example of a more proper usage. Basically, because people at my work seem to think that when I show them good programming practices,
      • I humbly submit an example of when SWITCH can go horribly wrong. The temptation to use labels for control flow when they are not required makes bugs like this more likely.

         while ( my $data = $t_sth->fetchrow_arrayref ) {
           my ( $amt, $id ) = @$data;
           $amt /= PRECISION;

           SWITCH: {
             $id == $CASH        && ($tcash        += $amt) && last SWITCH;
             $id == $ACCOUNT

        • Yes, I can try this one. I saw the bug when I saw the code. Maybe this one will show why they should avoid labels (although labels are good in deeply nested loops, they don't do that anyways).

          Maybe I can turn this into a "THAT IS FIRE, DO NOT TOUCH THE FIRE" ;-)

        • $id == $CASH && ($tcash += $amt) && last SWITCH;

          I saw the "bug" when I saw the code, but then I thought "the programmer wouldn't have used that construct if ($tcash += $amt) could ever yield zero!".

          I like pie.