Perl::Critic

Would you submit to having your code reviewed by a committed of Java theoreticians?

Because that is exactly what you are doing by submitting yourself to PerlCritic.

Fully 95% of Perl::Critic's (and by implication PBP) justifictions are as puerile as banning ball games from school playgrounds because participants might skin their knees.

Making their own mistakes and learning from them is how kids learn. Banning every construct and idiom, that might under some obscure circumstances cause the occasional program to fail, is like trying to wrap your kids in cotton wool. Overindulgent, counter-productive and ultimately futile.

Like the boy that cried wolf; perlcritic prematurely bellyaches at the merest hint of a possibility of trouble. And in the process, renders programmers that obey it, to a set of rule-driven automatons that never gain experience; lack any kind of innovation; and ultimately never acquire the programmer's greatest attribute: common sense.

Many will say (have said) that perlcritic is "only advisory". The problem is that unless you have acquired the experience of when the particular constructs and idioms that it decries voluminously with artificial & fictional reasoning, are useful & not; dangerous & not; perfectly acceptable despite their dangers, & not; you will never have the knowledge upon which to reject its advice. Or not.

Perlcritic is the thin end of the wedge to the de-skilling(*) of the programmer's art. Reject it. JUST SAY NO!

(*Look up that word. Learn from the history that underlies it. Remember the old fart's of today were yesterday's youth. And do not deceive yourself into thinking that the youth of today know anything; think anything; or try anything that their forebears didn't know, think or try 20 years before them. Those that ignore history are bound to repeat it.)

And I'll disagree, but just a little.

There are mechanical I-should-probably-always-do-this things that Perl::Critic can check for:

• Did you use strict and warnings?
• Did you remember to use 3-arg open?
And several other things that Perlmonks repeatedly urges people to do that are on the mechanical side, meaning that they are simply "did I remember to do this or not?" questions that are not syntactically or semantically invalid, but are reasonable standards to enforce on your code. If the requirement to do something is mechanical, then making the check to see that it is done mechanical is reasonably well-advised.

I do not currently run Perl::Critic against our codebase, but I can see that there are some - some - checks that might be useful - the "did I remember" ones. I do completely agree with BrowserUK that running all of the checks and just doing everything it says to do is very much the wrong way to go, mostly because you're abdicating your own judgement and knowledge of the code to something that does not actually understand the code at all.

Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful. Otherwise, it's like a to-do list that includes the things that someone else has decided people Should Do.

Metaphorically speaking, if you have a busy 20-something single woman living in Brooklyn and a forgetful 80-something man living in rural Arizona, the Brooklynite doesn't need a reminder to shake scorpions out of her shoes, but it might be critical for the Arizonan. Perl::Critic by default reminds you to be careful not to be mugged for your phone, but has no idea that scorpions even exist.

(Okay, to stretch the metaphor, it's actually warning you to not be mugged for your Walkman because it's never heard of cellphones.)

Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful.

Sorry. But that "you can configure it to your needs" argument simply doesn't hold water. Let's start with the extremes:

1. The experienced. Perler.

   When PC (thos initials say it all :) first came around, I ran it out-of-the-box against several scripts and modules -- some my own; some by authors I respect and trust -- and it just bugged me intensely.

   It whinged and whined and cried wolf about every other line of code. The only time I have ever seen so many warning messages was when I tried to compile my first Pascal program and mistakenly had used {}'s instead of BEGIN/END. The volume of output (from PC) was ludicrous; given the scripts and modules were all tested, well-exercised, thoroughly debugged code.

   First, I tried to # no perlcritic all the failing lines in one script of about 20 lines that had probably taken me 15 or 20 minutes to write, it took nearly an hour to understand what each message was meant to be warning me of -- there were a few warnings that without the benefit of PBP; I simply never did understand. The result was that the script almost doubled in size, and became unreadable because of all the garbage non-comments.

   So then I tried to evolve one of the modules to pass without disabling. I gave up on the script and the first two modules; because they simply could not be made complient and still work. That took almost two hours and the result wasn't like Java. It was worse. it over doubled in size because of all the useful idioms that had to be rewritten into prozaic generic syntac. And it ran substantially more slowly. But worse, with twice as many lines, it almost certainly contained twice as many bugs as a result. It was definitely twice as hard to understand (more lines; more to read and understand, for an experienced Perler), and therefore harder to maintain.

   So, to the idea that I could disable those warnings that I disliked. I did. I simply stopped using it. There's more about that further down...

2. The novice.

   The novice starts using PC up front; and discovers that every line of code he attempts to copy or adapt from any Perl books he has access to -- from mastering Perl to Perl in a Nutshell to Perl for Dummies and everything in between -- won't pass PC's default settings.

   But how can he configure it? He doesn't have the experience to know which warnings he should heed and which to ignore.

   Beginner's have enough trouble with warnings; if they get around to adding it, as often as not they end up commenting it out. With PC, even if they copy the literature slavishly, they still get whinged at for doing the wrong thing. Talk about discouraging.

... If I disable everything; what good is PC doing for me? It isn't But when I use the types of things it warns ne about; I do so with consideration at the time; what point is there to having it remind me?

For example: I purposely choose to use bareword file handles in top level scripts. I do this on the basis that different things should look different; and a top level script *OWNS* the global namespace so there is no conflict as modules should *never* mess with globals. And in modules -- complying with that rule -- I always use lexical file handles.

So now I would need two configurations for PC. And then another for another (personal) rule; and another; and another...SO then the game is deciding which of those configurations I should run against this particular script or module. But that is pointless because I already made my decision when I wrote the code.

And that's the second argument against PC. It does static analysis, after-the-fact. I do my analysis dynamically, as I write the code. Anything it chooses to tell me about, I've already made my decision about. (Or I don't want to hear it in the first place!)

And finally, it is completely possible to write totally unintelligible, crap, wrong and dangerous code that no amount of PC's static analysis will ever detect. Which means it still comes down to testing to determine whether the code does what it is meant to do or not. And once I've done my testing and concluded it works; I couldn't give two monkey's hoots whether some anal retentive, failed Perler, wannabe Java coder thinks the way I've achieved that is sliced bread or moldy goat's cheese.

Passing my tests won't guarantee that it is 100% bug free; but if it fails in use, it won't be down to anything that PC would have told me about.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I love it. The dissenting opinion... and it's a good one. You've made a very good case here. I have to take this into account; you've persuaded me a bit, and I think some changes are necessary.

Thank you.

Tommy

I'm going to have to pretty much entirely disagree with you.

I get the feeling from your arguments that you have your mind entirely made up to hate Perl::Critic, so I know nothing I say will convince you of it's usefullness. However, I have used it with multiple inexperienced Perl coders at work and found that it significantly improved their code quality. It introduced them to best practices that they weren't familiar with, and provided a sanity check for them against common mistakes.

They are inexperienced. They don't know common idioms and best practices. And they're never going to learn it without someone (or something) correcting them. Perl::Critic is a great start. Do they follow everything it suggests? No. But they're not complete idiots, incapable of doing research on their own. If something comes up that they aren't sure about, they search online, or ask someone else about it. They learn from it.

You seem to think that using Perl::Critic prevents people from gaining experience, although I'm unable to see any logic in that assertion. How exactly are people supposed to gain experience by making the same mistakes over and over, never realizing that they're making mistakes?

Perl::Critic helps immature Perl programmers improve. It helps out of date Perl programmers learn Modern Perl practices. It's an incredibly useful tool, and I personally have benefitted greatly from it's use.

Oh, yeah; I do run my code through it regularly, too. It makes for a great sanity check to make sure I didn't make silly mistakes.

Downvoted!

Here's why: You do not put forward any arguments for either the authority or efficacy of the result of compliance with P::C. Nor do you state an single example or any reasoning for your conclusion that P::C improves beginners code.

You go one to say that: "But they're not complete idiots, incapable of doing research on their own."; clearly indicating that not everything P::C recommends is sacrosanct. But which ones? How does the beginner know which of the thousands of spurious and pointless whinges that P::C spews at them is worthy of further research?

And, when they reach different conclusions to you; are you going to accept their "beginner's research" judgement in good faith?

Or will you simply judge anyone who has a differing opinion to you, not as one who has taken the time and research and thought to have reach the point of having their mind entirely made up; but rather as someone who exhibits "hate" for a piece of software, as you have accused me?

You simply state: "I like; I use it; therefore it must be good."

Which is the exact same problem as P::C. It codifies an opinion as having authority on the basis of puerile and simplistic justifications. And without open and transparent debate and the reaching of some kind of consensus; it does not bear that authority.

Pick (almost) any single one of P::C critiques and open up the discussion here to all comers comments; and I'll bet you'll never reach a consensus; without you give a specific example of the critiqued construct or idiom in situ. And even if you get a consensus for that specific usage, it will be only for that specific usage; and probably a contrived one at that.

And for every supporting example; an alternative challenging example will be contrivable.

And that is the crux of my position; P::C does not (and cannot) take context into consideration. It attempts to make black or white that which is inherently gray.

And they're never going to learn it without someone (or something) correcting them.

Exactly so. But demeaning the programmer's art and experience by allowing the substitution a dumb pattern matching algorithm, for proper (human) code reviews, is the greatest danger of a piece of software like P::C. It diminishes the knowledge, experience, intuition and dedication of the programmer to that of an electronic cardboard cutout.

A surgeon friend of mine agrees that software is at least as hard and complex as surgery; and it takes 7 - 10 years before a surgeon is considered qualified.

If you personally find P::C useful to you, I have no problem with that -- it it your time and cycles you are wasting -- but suggesting that it is a good way to teach new programmers is bordering on criminality as far as I'm concerned.

I've spent 35+ years acquiring my programming skills; and I'm not about to substitute my experience, intuition and judgement with a dumb text matching script. And I heartily commend anyone who considers programming to be more than a rote-learnt way to earn a crust, to consider carefully the efficacy of same.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.
p

Thanks, I've added Devel::Cover coverage to my tests via Dist::Zilla::App::Command::cover. What a great tool!

Tommy

Vim

• Emacs

Debian

Any form of *nix environment does for me. I do the majority of my Perl coding at work on a Winbloze 7 box and Cygwin/X.

I'm surprised your list did not included:

• strict
• warnings
• Carp

For me I'd add the following:

• MIME::Lite
  or some other module that allows me to send EMail with binary attachments. I show MIME::Lite on my list because over the years that's the one I use most.
• XML::Simple which I typically use for configuration parameter storage for my more complex Perl projects.
• Subversion, CVS or other version control environment
  I call this "super save" because it means there's a version of what I'm writing someplace else. I do frequent commits to my SVN environment just so if I do something really stoopid to my workspace I can recover easily. It also means that I can work on one host, do my debugging and use svn co http://..... to pull the latest version onto another host. I notice you have git in your list, but I ain't ready to give up my investment in time to convert my subversion repositories to git just yet.
• CPAN Search to look up particulars on various CPAN related modules that I'm using.

Also, no particular order...

• SciTE
• perldoc cpandoc
• Module::Package / Module::Package::RDF
• prove forkprove
• Test::More and occasionally Test::Exception, Test::Warn, Test::Fatal, Test::Warnings, etc.
• Devel::Cover
• cpan-upload
• Mercurial
• perlbrew
• cpanminus cpantimes

Many SciTE customizations?

Nothing especially earth-shattering...

Read more... (5 kB)
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

1. vim
2. Perl in a Nutshell from O'Reilly
3. Other ORA references on the bookshelf
4. Additional references in e-book form. (I am old-school, after all)
5. PerlTidy
6. PerlCritic
7. Revision Control (currently git, I haven't found anything I like better)
8. Nemeth, Snyder, and Hein -- Linux Administration; NSH and Seebass -- Unix System Administration
9. Ubuntu is my primary development OS, The code runs on Linux and/or Win7+Activestate

Perl in a Nutshell? Yikes! It's ancient (1998). Is it truly still useful to you today as a reference?

It just seems like it must be largely obsolete now, and there must be better books to use today as Perl references. I understand "old school" and its many positive attributes, but the Nutshell book is a relic of a bygone Perl era.

Jim

The Nutshell isn't used much a reference at home, but in a contract where they are still running Perl 5.8.x and can't upgrade, it's a God send. I have learned too many neo-perlisms from working with more current Perl's at home; so if I can't find it in the index in Nutshell, then I really can't use it in my for-pay code. (And yes, I know about perl -f, I just don't remember it as often.)

----
I Go Back to Sleep, Now.

OGB

Hmmmm... well I agree with you on a few. In no particular order, here is my list:

• Vim
• perldoc/cpandoc
• Programming Perl and Learning Perl
• Git with Github
• strict and warnings
• Perlmonks and Stack Overflow
• Perl::Critic
• Windows 7/8 - sometimes Ubuntu
• Pencil and paper - necessary when designing and brain storming
• Firefox or Chrome

I could probably go on for a while, but those are my Top 10.

• Data::Dumper
• String
• Warnings
• vim plugins - for perl which would provide file header, highlight syntax errors and automatic close braces

• emacs
• sshfs
• git or subversion
• the perl debugger

I usually keep it really basic;

• Google to hit all documentation sites at once, but usually that's just perldoc and perlmonks.
• notepad++
• a flag in the code to repeatedly re-eval the source for "live" editing/debugging
• a VM to run the code under windows too
• a test.pl file for TIAS checks
• SVN repo

For mi just Crimson Editor

CPAN

My Reference Camel book (PDF)

That's all I need.

• vim
• ack
• bash
• git
• prove
• 2nd monitor

Oh. My...

Tommy

I would add tkpod for documentation review

• Emacs (with integrated Perl Tidy)
• cpandoc
• Perl Debugger/re.pl
• perlmonks.org
• Linux
• GNU Screen
• Perlbrew
• cpanminus