http://www.perlmonks.org?node_id=596748


in reply to Re^2: Module Announcement: Perl-Critic-1.01
in thread Module Announcement: Perl-Critic-1.01

use English qw(-no_match_vars); eval { die 'A horrible death' }; print "Something died\n" if $EVAL_ERROR;

Hmm, well that is one way to do it, but I am not sure it is a better way. IMO English.pm ends up just obscuring the more common "special" punctuation variables which any decent Perl hacker will already know by heart. Not to mention the fact that I REALLY DONT LIKE $SOURCE_CODE THAT @SHOUTS AT $ME ALL THE *TIME.

If those were double-quotes instead of single-quotes (which they probably were) then the warning was precisely correct.

Nope, they were not double quotes. My personal policy is to only use double quotes when interpolating, and single quotes otherwise (so that accidental interpolation is just not possible). This is why this one threw me, cause it just seems wrong.

Perl::Critic is lenient by default. Normally, it only reports the most severe issues (the relative severities are configurable). However, the web-service is currently configured for maximum strictness. I suppose I should loosen that up a bit. One of these days, I'd like to expose all the Perl::Critic configurations through the web-service, but that's a ways off.

I agree with xdg, a more lax policy on the webservice and/or the ability to select that more lax policy would certainly be a nice addition. If for no other reason then to demonstrate the power and flexibility of Perl::Critic.

Now please do not misinterpret me, I think Perl::Critic is a very important tool, and one which the community desperately needs. However nothing will turn people off more than 40-50 lines of pretty severe warnings only maybe 2-3 of which are actually valuable advice. A more lax policy (this is Perl after all) would likely help adoption even if it lets a few of TheDamian's edicts slip by.

-stvn

Replies are listed 'Best First'.
Re^4: Module Announcement: Perl-Critic-1.01
by Herkum (Parson) on Jan 26, 2007 at 18:08 UTC

    I can understand not wanting the code to shout. However, when you are working with special system variables. They are so compact and non-descriptive they can be problematic to identify and debug. Imagine looking at $/ and meaning to use $\, talk about subtle.

    English may have code that SHOUTS but it brings attention to itself with the upper-case syntax and is more descriptive than the built-in variable names. There are good reasons why TheDamian recommended its use in PBP.

      Imagine looking at $/ and meaning to use $\, talk about subtle

      I used to have trouble remembering these until I read somewhere about thinking about them like funnels -- just mentally remove the "S" from the "$".

      |/ is a funnel *in* ($/) |\ is a funnel *out* ($\)

      That doesn't change your point about subtle -- it's just the mnemonic I picked up somewhere.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      However, when you are working with special system variables. They are so compact and non-descriptive they can be problematic to identify and debug. Imagine looking at $/ and meaning to use $\, talk about subtle.

      I suppose a lot of this really depends on how oftern you need to use special punctuation vars. Most of my $work code (medium-large web app) I never use anything other than $@. And the longer version of this (IMHO of course) is just overkill.

      English may have code that SHOUTS but it brings attention to itself with the upper-case syntax and is more descriptive than the built-in variable names.

      I can understand wanting to bring attention to certain usages of these variables, but not all. With more common variables and usages (like $@) it ends up being a distraction to the visual flow of the code, and drawing attention to an "exceptional" case.

      -stvn