Re^5: Modern Perl and the Future of Perl

[shmem]

The use of Perl::Critic is fundamentally wrong.

Developing good, then best practices is a good thing; agreeing upon naming conventions and code style also is, nobody denies that, and BrowserUk certainly doesn't.

Good coding practices aren't if imposed and applied after the fact.

Good coding practices are a programmer's attitude towards the job at hand, and this attitude will not develop under any imposition of rules whatsoever, but by understanding them and internalizing them. Best practices are such only in practice, when you are coding.

Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.

Perl::Critic alienates what has to be a programmer's internal state into a technical instrument, which is wrong. As it is applied after the fact, it is a tool for imposition, which is a hindrance to really developing good practices.

[chromatic]

Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.

Some P::C policies detect code that is undeniably wrong. For years, I recommended the use of UNIVERSAL::can and UNIVERSAL::isa as functions until they bit me in real life. For years, there was no warning on pseudo-static lexical variables (Perl 5.10 added this).

It's not clear that those constructs are always bugs, but they all deserve investigation. P::C can detect those in a large codebase, along with other constructs which we now know to be risky.

Now I don't know what's happened to you and BrowserUK that your hands jerk off the keyboard in shock whenever someone suggests that your team should consider agreeing on the use of a tool that can help you identify things in code that you need to think about, but that's fine. Don't use them. If they give you nightmares or make a bunch of nametags for you that say "Hello My Name Is Winston Smith," then you don't have to use them.

Me, I think they can lead to better code. You'll never see me use the default vanilla set of policies, but you do see me taking advantage of other good tools such as profilers, unit tests, tags, version control, and POD checking tests because I don't trust myself to get everything right the first time. I'm perfectly happy disabling a P::C policy if it doesn't help me write better code, and if the burden of maintaining policy files is greater than the benefit I get from using P::C, I'll throw it out.

I don't see how that means I'm telling coders to turn off their brains and march back into their drab gray cubicles. Frankly, anyone who uses any of these good tools as an excuse not to think and not to do good work has no place on my team.

[shmem]

It's not clear that those constructs are always bugs, but they all deserve investigation. P::C can detect those in a large codebase, along with other constructs which we now know to be risky.

These risky constructs deserve a prominent place in e.g. perltrap (which up to this day is full of obsolete perl4-perl5 traps. I'll try to write a patch.) That's all that is necessary. That documentation should show up in the perl docs, not as a Perl::Critic policy complaint after the fact.

If somebody uses risky constructs in production code, that programmer is a risk to your business. And risky constructs aren't just the ones you mention, but every half-known construct.

Do you still occasionally use pseudo-static lexical variables when you shouldn't? Don't code drunk, then. Do you need Perl::Critic to detect them in your code? I bet all you get is false positives.

Now I don't know what's happened to you and BrowserUK that your hands jerk off the keyboard in shock whenever someone suggests that your team should consider agreeing on the use of a tool that can help you identify things in code that you need to think about, but that's fine.

It's because it is the wrong tool which doesn't solve the problems it promises to solve!

I have much the same reaction whenever I hear of people that have a "personal firewall" on their box. I'm always glad if I can direct them to the Personal Firewall FAQ. If you need Perl::Critic, your problem is somewhere else. See my other post.

[chromatic]

Don't code drunk, then.

Yeah, and if I can go 10 seconds without writing a bug, I can go 30 seconds without writing a bug. If I can go 30 seconds without writing a bug, surely I can go 2 minutes without writing a bug. If I can go 2 minutes without writing a bug, I can go 20 minutes without writing a bug, and so on, and so forth, ad infinitum.

Likewise a team that always did the right thing every time without having to think about it would never need a software development process. Let me know if you ever hear of such a team.

I can often go 10 seconds without writing a bug. I still write tests though.

I sometimes realize a few months into a project that I've been making a mistake for a while, and I need to find and fix it every time it occurs in my code. Sure, there's grep and App::Ack, but they're linear textual searches (regexes notwithstanding), and there's a big difference between that and a search over the canonical tree structure of Perl documents. P::C gives me a way to do that, and to stop those problems from coming up again in the future.

It's nice that you have the luxury of never making mistakes. If you can teach people everywhere how to stop being not perfect while coding, I'll stop recommending the use of tools which, when used intelligently, can help them code better until they reach your level of transcendent perfection.

[Mutant]

I guess it really depends how you want to use the tool. There are a lot of powerful tools in the world (not just in programming). You (or some organisation) can choose whether the tool is your slave or master.

Some people *want* the tool to be their master. Whether you or I think that's a good idea, it's obviously a very popular approach - it basically sums up Java (or at least the popularity of Java, although things may have changed somewhat). People have large legacy code bases of Perl and programmers who are used to the Java Way trying to maintain it. TIMTOWTDI applies even here. Why not let them do it?

But Perl::Critic is still just a tool. You can still be the master if you want. Set the rules up as you wish, and allow your programmers to break those rules at will (with sound justification of course). If they get annoyed with particular rules, turn them off completely! Or don't use it at all. You're the master.

[shmem]

There's a big difference between learning something, and being trained at something.

You don't have good practice as long as you need a tool that beats you into submission. You don't have good practice as long as all you have is just habit.

You can train a horse to stamp it's hoofs resembling numbers according to arithmetic questions you speak. Does that make the horse a mathematician?

You have good practice when you can adapt your coding style to your audience - your team, your customers, your module users, your task, the budget. To be a good orator you need to know grammar, rhetoric, fallacies, intonation and the comprehension level of your audience, and attention and applause are your reward.

To put it bluntly:
Perl::Critic is a utterly useless tool on the path to mastery. It is good for training skilled dogs.

Note that I am not speaking of Damian's "Perl Best Practices" Book here.

The only use I can conceive for Perl::Critic is occasional, in the way I use perltidy. You don't write messy code with garbled indentation and messy line breaks and run that code through perltidy after the fact, do you?

If you need Perl::Critic to enforce a coding style, you have a problem that lies elsewhere.

[mr_mischief]

I think the whole "beats you into submission" is more extreme than what most proponents of Perl::Critic mean.

My understanding of how best to use something like Perl::Critic is this:

• I can take code I'd been meaning to refactor, and figure out automatically which parts vary most from my usual current style. Those parts that differ most in style practice probably also differ most in usage of language features, since both tend to change (hopefully for the better) over time.
• I can, as a new member of a team, run my code through Perl::Critic with the team's settings a few times as a gentle reminder of where my habits differ from the rest of the team. The longer I'm with the team, the less I need such guidance because my habits will become more similar to those I'm programming with over time.
• I can, as an intermittent contributor to someone else's Open Source project, save them some time reformatting my code to their standards if I simply follow their standards rule set before submission. Since it might be very different from my own normal style, an automated check might help me change a few things before sending a patch.
I don't think any of those goals are necessarily narrowing my ability to innovate or to express my creativity in my code. I just think they can help people stick to conventions they were intending to stick to anyway, as a gentle reminder.

All that said, I almost never use the tool because I do very little work closely connected to other developers lately and I pretty much settled on my style of code some time ago. I do pull it out if I'm digging up nuggets of my sad older code or if I'm doing a hit-and-run patch like the scenario I mentioned. Most of my code older than my current coding style isn't worth reusing rather than rewriting anyway, I'm afraid.

[jplindstrom]

If you need Perl::Critic to enforce a coding style, you have a problem that lies elsewhere.

No. Because people make mistakes. Not all of the time, but some of the time. I'll give you an example.

Perl::Critic runs every time I open a file and highlights, directly in the source code, whenever there is something to complain about according to the policies I haven't disabled (which I spent quite some time doing in the beginning).

But nowadays I never think about this because 99% of the time there is nothing to report and Perl::Critic is silent.

But sometimes there is something to report and one of the lines of code is blue, begging for attention.

Several times over the last couple of months I've opened files in our code base at work and seen the warning that there is "code before strictures enabled", i.e. no "use strict".

Now, most of these have been five-liner .t files used to set up a test framework. So no biggie, no harm done, nothing was really broken.

But one of the files was a proper module where someone had missed to "use strict;". There was lots of code without strict. And sure enough, when I added it, the source didn't compile because of an undeclared variable.

So Perl::Critic actually helped me find a bug which was introduced by someone making a mistake.

Now, having this little aid will prevent me from making that particular mistake.

I have loads of little guidelines, conventions, and heuristics for how to do things in order to not screw up all the time. Very few of them happen to be Perl::Critic policies, and just a few of them would be useful to implement as policies, but for the ones that makes sense... why not?

Having said all this, I share your concern that Perl::Critic policies will be used as "rules" rather than "guidelines" (but as usual, you have to know why the rule is there, or that there is a rule to break in the first place before you have earned the right to break it).

I also see the risk that in some environments / organizations / projects Perl::Critic policies risk being something imposed on programmers from above, rather than embraced from within the team itself.

/J

[chromatic]

enforce

I'd love to have a discussion about how to help novice Perl programmers write good code, and how to help them train their senses and tastes to keep them out of trouble, but if you're more interested in arguing with words I never said and points I never made, you're more than welcome to have your discussion without me.