horrendo has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I'm trying to clean up some existing code to pass perlcritic.

One of the common 'styles' is to have a separate method to trap signals. For example : 

sub trap_signals {
  $SIG{CHLD} = \&handler;
  :

[download]

Now, perlcritic wants me to make a local copy of $SIG (as per page 81 of Perl Best Practices). However in this case the local copy defeats the purpose.

I can of course do something like : 

sub trap_signals {
  my $sig = \%SIG;
  $sig->{CHLD} = \&handler;
  :

[download]

It passes perlcritic but this seems to me to make the code more obscure and no 'safer'.

Is there a 'preferred' approach for dealing with this situation?

Thanks a lot.

H.

Replies are listed 'Best First'.
Re: Doing the right thing by perlcritic
by ikegami (Patriarch) on May 26, 2010 at 04:18 UTC

    (<pre> shouldn't be used here. Use <p> to start paragraphs, <c>..</c> around code, data and outputs)

    Are you saying the following is no good for some reason? 

    sub trap_signals {
  local $SIG{CHLD} = \&handler;
  :
}

    [download]

    It seems quite odd to set $SIG{CHLD} in a sub if you want it to have a global effect. But let's say it is a big init function, then you could either silence the critic (since the global effect is desired) or change 

    sub init {
   $SIG{CHLD} = ...;
   ... init code ...
}

{
   init()
   ... main code ...
}

    [download]
    to 
    sub main {
   ... main code ...
}

{
   local $SIG{CHLD} = ...;
   ... init code ...
   main();
}

    [download]
[reply]
[d/l]
[select]
      (Sorry about the <pre> tag. I saw it was 'approved' and was just being lazy)

      Thanks for such a quick response. I'll take on your suggestion.

      Cheers,

      H

[reply]
[d/l]

        As a registered user, You still can fix it yourself and switch the <PRE> tags to <P>

[reply]
[d/l]
[select]
Re: Doing the right thing by perlcritic
by bluescreen (Friar) on May 26, 2010 at 23:59 UTC
    Perlcritic & PBP are just guidelines they are not the bible, they are cool stuff tough.
    What I'm saying is, sometimes I like to be explicit about returning undef and if I run perlcritic to that it will point out that there is something wrong with my code. So I would recommend you to use perlcritic and if you found cases like these apply your own criteria ( after you understand the reasons why perlcritic thinks that there is an error )
[reply]

Back to Seekers of Perl Wisdom