Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
"be consistent"
 
PerlMonks  

Re: Module Announcement: Perl-Critic-1.01

by stvn (Monsignor)
on Jan 26, 2007 at 13:13 UTC ( #596706=note: print w/ replies, xml ) Need Help??


in reply to Module Announcement: Perl-Critic-1.01

Leaving the whole thing about RCS keywords (my grandfather used RCS, I use subversion ;) and specifc POD sections (maybe I don't want to name them the way TheDamian does) aside, I am surpised at a couple of things in the output:

  • Magic punctuation variable used at line ...
  • The magic punctuatinon it is talking about is $@ without which I could not really catch exceptions. I think that is a little severe.

  • Useless interpolation of literal string at line ...
  • I don't even get that one because the line in question is basically something like this:

    confess 'Some error happened because ' . $obj->foo . ' blew up';
    I would have to say that this string was far from useless.

  • Subroutine does not end with "return" at line ...
  • Now, I can understand this for large subroutines, but the sub in queston was basically this:

    sub mumble_path { join ", " => split '/' => (shift)->get_path }
    I would argue that adding return to something like that would be just adding noise.

Of course I know you are supposed to be able to customize Perl::Critic to your own tastes, but I wonder if the default settings are maybe not too severe? My first thoughts when I saw all the output was similar to BrowserUK, I felt like I was looking at some overpriced Java middleware exception stack trace.

-stvn


Comment on Re: Module Announcement: Perl-Critic-1.01
Select or Download Code
Re^2: Module Announcement: Perl-Critic-1.01
by jthalhammer (Friar) on Jan 26, 2007 at 14:00 UTC
    The magic punctuatinon it is talking about is $@ without which I could not really catch exceptions
    use English qw(-no_match_vars); eval { die 'A horrible death' }; print "Something died\n" if $EVAL_ERROR;
    Useless interpolation of literal string at line ...
    I don't even get that one because the line in question is basically something like this:
    confess 'Some error happened because ' . $obj->foo . ' blew up';
    I would have to say that this string was far from useless.

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

    sub mumble_path { join ", " => split '/' => (shift)>get_path }
    I would argue that adding return to something like that would be just adding noise.

    You certainly can argue! Perl-Critic-Lax is a suite of slightly more forgiving versions of several Policies. Perhaps you could write a new module for it.

    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.

    -Jeff
      However, the web-service is currently configured for maximum strictness. I suppose I should loosen that up a bit.

      I suspect you'll get more positive reactions if you tune the level of strictness for what you think "typical" (hah!) programmers would find helpful. Not everyone takes PBP as gospel.

      Alternatively, even if you don't expose all the configuration via the service, perhaps either having two options "Analyze my code aggressively" or "Analyze my code mildly" would help. Or perhaps just grouping the output in descending order of severity -- so people see the highest severity issues first and then can decide where to stop paying attention.

      -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.

        Agreed! I tried out the web version on one of my modules, and instantly dismissed it as (1) needless pedantry, (2) uninformative, and (3) pimping PBP:
        Code is not tidy at line 1, column 1. See page 33 of PBP. Severity: +1
        Subsequent lines did not improve my opinion of the module.
      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

        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.

      confess 'Some error happened because ' . $obj->foo . ' blew up';
      If those were double-quotes instead of single-quotes (which they probably were) then the warning was precisely correct.

      No, that can't be it, because the strings in question contain none of the things Critic cares about, namely unescaped $. or @. and escaped metachars. I suspect that your parser is not detecting the fact that the confess argument is actually three strings concantenated together, and it's thinking the $obj is inside the string.

      Anyway, I can't verify any of the above, since I can't get the confess line to trigger a warning from the web-based Critic now.

      A word spoken in Mind will reach its own level, in the objective world, by its own weight

      update: I overlooked the -no_match_vars (ETOOMUCHNOISE? :-), the impact of use English isn't that nefarious in the advised usage. But even so, I stand to my statement.

      jthalhammer,

      The magic punctuatinon it is talking about is $@ without which I could not really catch exceptions
      use English qw(-no_match_vars); eval { die 'A horrible death' }; print "Something died\n" if $EVAL_ERROR;

      Please go read perlvar. I include the relevant bits here:

      BUGS
      Due to an unfortunate accident of Perl's implementation, "use English" imposes a considerable performance penalty on all regular expression matches in a program, regardless of whether they occur in the scope of "use English". For that reason, saying "use English" in libraries is strongly discouraged. See the Devel::SawAmpersand module documentation from CPAN ( http://www.cpan.org/modules/by-module/Devel/ ) for more information.

      Suggesting use English to avoid the use of $@ is just

      plain silly

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

        I dislike English, but it does say: use English qw( -no_match_vars ) ; # Avoids regex performance penalty. Nobody fixed the perlvar page maybe?

        -Paul

Re^2: Module Announcement: Perl-Critic-1.01
by petdance (Parson) on Jan 26, 2007 at 17:37 UTC
    It's better to be strict by default. If people only turned on the warnings that they thought were useful, they wouldn't know about the other warnings that are helpful that they discovered by mistake.

    People use lint and it's hardcore stringent by default, too.

    xoxo,
    Andy

      It's better to be strict by default.

      As a coding practice, I agree. As a marketing device, I don't. First impressions count and missing RCS variables probably shouldn't be the first impression people get from the Perl::Critic website.

      -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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://596706]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2014-04-20 08:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls