Perl::Critic - Automatically review your code | Hacker News Reader

Perl::Critic - Automatically review your code

perltraining.com.au

45 pointsgnosis32 comments

I'll just leave this here:

https://github.com/illusori/emacs-flymake-perlcritic

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

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

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

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

libperl-critic-perl is the core Perl Critic. libtest-perl-critic-perl is for using Perl Critic in tests.

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

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.

when dealing with cpan, i think you should separate between the repository itself, which is surely more up to date than debian or ubuntu repos (because this is where debian or ubuntu pull from anyway)

and the command line interface, you have cpan, cpanp (cpan plus) and cpanm (cpan minus)

some cpan interfaces work better than others

To update all packages use:

cpan upgrade /(.*)/

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.

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.

There are trade-offs. There is no perfect solution.

That's why I just use cpan2deb. There's a few modules that won't package properly with it, I should file some bugs.

I also use cpanm when I have a need to be separate from vendor, but generally in the worst-case admins prefer to only maintain one set of perl/cpan rather than two.

"i find the centralized packaging system flawed ... because on the long term its unsustainable"

Could you elaborate on why you think this?

i hope engaging in this clearly off topic, wont offend others

linux and foss rely on volunteer effort, therefore efficiency matters a lot, inefficient system will loose volunteers and momentum, i think its surprising the system lasted for so long , but then i believe the number of surviving distros is in decline and even less so the number of package management system

anyway, maybe my usage of the word centralized and decentralized term is wrong

cpan can be viewed as centralized, it is a single storage space for all modules

i just believe that is too much waste, in having to repackage each application to different systems, there must be a better way, where the effort will be more efficient and require less resources

maybe the opposite of what i said is true, maybe we need to centralize over one package system to reduce the effort, or in other, maybe we need we centralized over a single system and repo, to be able to decentralize the effort

I thought most people would have as main reason to not mix their own stuff with the system Perl?!

And you want multiple Perls installed, anyway. Backward compatibility is a target in the Perl world, but stay safe... ("This is the versions at the job servers. This is what I do my hobbies with. Also, I need to keep a 5.8.8 Perl, to make certain so X works with that golden oldie.")

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

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/

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

For JavaScript, one option is the Closure Linter

https://developers.google.com/closure/utilities/

(disclaimer: I helped write this when I was working there)

Inspired by this I wrote https://bitbucket.org/sirpengi/php.critic

There is, google for something like php lint or js lint.

For PHP, there's PHP_CodeSniffer, though it's not quite the same thing.

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

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

http://clang-analyzer.llvm.org/

For python: pylint is nice

http://www.logilab.org/857

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.

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

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

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

Q: What's the difference between "better" and "worse" Perl code? A: http://www.matthewsdiehl.com/wp-content/uploads/2009/01/rock...

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

Reply on news.ycombinator.com