Module Announcement: Perl-Critic-1.01

After more than 18 months of development, Perl-Critic has reached it's first major release! Version 1.01 is now available on a CPAN mirror near you.

For those of you who aren't familiar with it, Perl-Critic is a highly flexible static source code analyzer (like lint, but for Perl code). It automaticaly detects potential bugs, awkward constructs and over-complicated code. Most of the rules are based on TheDamian's book "Perl Best Practices".

No matter what your personal preferences are, Perl-Critic can help you and your team write more consistent, robust, and maintainable code. Numerous open-source projects and commercial development shops have adopted Perl-Critic as an integral part of their development process. And at my $work, we use Perl-Critic as a tool for coaching junior developers.

So I invite all of you to give Perl-Critic a shot. If you want to see what it does without installing anything, try using the Perl-Critic web service at http://perlcritic.com.

I sincerely thank all the PerlMonks who have contributed code, ideas, and valuable feedback throughout the Perl-Critic project.

-Jeff

Comment on Module Announcement: Perl-Critic-1.01

Replies are listed 'Best First'.

Re: Module Announcement: Perl-Critic-1.01
by stvn (Monsignor) on Jan 26, 2007 at 13:13 UTC

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';
[download]

far

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 }
[download]

BrowserUK

-stvn

[reply]
[d/l]
[select]

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;
[download]

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';
[download]
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 }
[download]

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.

[reply]
[d/l]
[select]

Re^3: Module Announcement: Perl-Critic-1.01

by xdg (Monsignor) on Jan 26, 2007 at 15:13 UTC

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.