

Perl::Critic - Automatically review your code - gnosis
http://perltraining.com.au/tips/2009-02-05.html

======
npsimons
I'll just leave this here:

[https://github.com/illusori/emacs-flymake-
perlcritic](https://github.com/illusori/emacs-flymake-perlcritic)

------
lazyjones
This is essential for Perl programming, along with perl -MO=Lint -c <file>.
The downside is that it is slow and takes away the fast turnaround times
you're used from scripting languages, checking every file after editing (as
you should) takes longer than compiling a Go program ...

~~~
npsimons
I've been using "perl -tTW" along with "use strict; use warnings; use
sigtrap;" before I found out about Perl::Critic, which works nicely with
flymake
([http://www.gnu.org/software/emacs/manual/html_node/emacs/Fly...](http://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html)).
None of it has seemed to slow me down too much.

The thing about these tools (along with other checkers, warnings, errors,
etc), for me at least, is they tend to be corrective. I learn not to keep
making the same mistakes, if for no other reason that to avoid the "pain".
This is just icing on top of the fact that these tools can be automated,
especially to prevent code from being checked in or merged when it violates
these checking systems.

------
hardwaresofton
You might have an error with syntax highlighter on your page, it's making a
dialog box telling me it doesn't have a brush for perl

------
ratsbane
For Debian/Ubuntu: sudo apt-get install libtest-perl-critic-perl

~~~
systems
i dont see how the debian maintainers can keep up with cpan, just use cpan for
perl

generally speaking, i find the centralized packaging system flawed ... because
on the long term its unsustainable

cpan is decentralized by the way, because module makers package their modules
themselves for cpan

~~~
ratsbane
I go back and forth on this. Aptitude seems more reliable in general than
cpan, at least in the sense that cpan installations fail more frequently than
apt.

Also I assume that cpan packages reflected through apt will be updated with
apt-get update, while cpan has no similar update-all mechanism (AFAIK).

One advantage of using cpan is that if you're developing on a Mac and
deploying on a Debian distro you can use the same commands on both systems to
pull in the packages you need.

~~~
Moto7451
To update all packages use:

cpan upgrade /(.*)/

~~~
gnosis
That doesn't seem to work for me.

First, typing that in the shell gives me an error:

    
    
      zsh: no matches found: /(.*)/
    

So, I tried typing:

    
    
      cpan upgrade '/(.*)/'
    

Which at least kept my shell from trying to expand the last argument, but cpan
complained:

    
    
      Warning: Cannot install upgrade, don't know what it is.
      Try the command
    
        i /upgrade/
    
      to find objects with matching identifiers.
      Sorry, install with a regular expression is only supported when unambiguous.
      Rejecting argument '/(.*)/'
    

So, instead at the shell I just typed:

    
    
      cpan
    

Then, at the cpan[1]> prompt, I typed:

    
    
      upgrade
    

That seemed to work.

~~~
Moto7451
Sorry meant the CPAN shell. Should have reproduced the prompt better. Also it
does appear that the regex isn't required any longer. That's certainly nice.

------
ancarda
Please tell me there is something like this for PHP or JS?

~~~
dharbin
JSHint[1] seems to be the most popular JS linter, although I believe
Perl::Critic to be the more powerful of the two tools. I've always appreciated
how Perl::Critic allows you to write your own rules, and I wish JSHint was so
customizable because I have coding standards I'd like to automate that don't
exist in JSHint's options.

1: [http://jshint.com/](http://jshint.com/)

~~~
lazyjones
> I believe Perl::Critic to be the more powerful of the two tools.

It is quite limited by Perl's quirky syntax, unfortunately ("only Perl can
parse Perl"). Last time I checked, it would miss e.g. all warnings for
anonymous subs:

    
    
      # triggers "Subroutine "foo" does not end with "return" at line 5, column 1.  See page 197 of PBP.  (Severity: 4)"
      sub foo {
          my $s=shift;
      }
    
      # triggers no warnings 
      my $x = sub {
          my $s=shift;
      }
    

This is a bug/limitation in PPI (which otherwise does a great job with the
mess that is Perl syntax) ... I'd assume the various JS analysers can do a
more thorough job.

------
Snowda
Anybody know a similar piece of software for C or Python?

~~~
mcarreno
For C, C++ or Objective-C check out the Clang Static Analyzer.

[http://clang-analyzer.llvm.org/](http://clang-analyzer.llvm.org/)

------
dj-wonk
Q: What's the difference between writing Perl and taking a severe beating? A:
Nothing. The wonder of Perl is that it helps you get the latter without
needing any external assistance.

~~~
dj-wonk
You downvoters are so uptight! Are attempts are humor against HN guidelines?
Surely (or maybe not!) you can appreciate a good joke? Unless it hit too close
to home, pun intended? (Disclaimer: I do not advocate taking a severe beating,
Perl-inflicted or otherwise.)

~~~
maxerickson
I didn't vote on any of your comments here. Humor doesn't go all that well
here, my take on that is that it is of course subjective, and a whole lot of
it is quite a bit less original than maybe the commenter thinks (which turns
it into a sort of noise).

------
dj-wonk
What's the difference between asking how to improve Perl code and Satan going
to confession? The latter might have some chance of redemption.

~~~
dj-wonk
Q: What's the difference between "better" and "worse" Perl code? A:
[http://www.matthewsdiehl.com/wp-
content/uploads/2009/01/rock...](http://www.matthewsdiehl.com/wp-
content/uploads/2009/01/rock-hard-place-simpsons.jpg)

(I submit these slides in support of the previous rhetorical question:
[http://www.oualline.com/talks/perl.pdf](http://www.oualline.com/talks/perl.pdf))

