Re^6: Modern Perl and the Future of Perl

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

[shmem]

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.

These statements don't add anything to the discussion; you try to make me look like a fool, which is a rhetoric trick I deeply detest. Thank you.

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

Yeah, me 2. And then you run Perl::Critic over your code, do you?

I write bugs, and often nasty bugs, and I do that despite knowing Perl Best Practices, and those bugs aren't product of best practice violation. It often takes me a ridiculously long time to spot them, because I am blind to them. So is P::C.

But then, I am quick in spotting bugs in code others wrote. My posts here back that.

I go over that code, see a different mindset, try to get what they thought, and how they think, how they lay out their thoughts and how they cast them into code. It is like exploring an unknown land, or deciphering an unknown dialect. The mere difference to my own thoughts incite my curiosity and my concentration. I see patterns, go over the rough edges, compare idioms I find to my own. As I re-create the logic of the programm I follow, suddenly I see what's wrong. There.

How would that be if everyone would code as I do? Would that also be an exciting journey into somebody else's thoughts? I guess not.

Would I have developed the same ability of spotting oddities if all perl code I have seen had been uniform? I guess not.

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.

So you write a rule for Perl::Critic to detect all occurrences, and succeed with that? Good. That sounds like just occasional use of P::C, and a good one, which has nothing to do with setting up a set of rules and use P::C to report violations to coding standards.

And, you spotted that mistake without P::C, did you? And fixed the rules afterwards?

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.

Again you are trying to make me look like a fool. You don't need that; leave that to Cop.

Needless to say that I'm far from perfect and will never be. There's no way to teach people how to stop not being perfect, but there are ways to make them good coworkers, to make them a good team, to make them good code readers. P::C is not useful to get accustomed to a wide variety of idioms, patterns and ways of expression, because it reduces the set.

And that richness in patterns, ideas, idioms is what makes a good programmer. Knowing how the language works you have at hand makes a good programmer. Being able to read someone else's code makes a good programmer. Writing your code in a way that others grok it because you just know you want to do it that way makes a good programmer.

P::C isn't useful to achieve any of those goals. I'm willing to discuss that further.

But even a tool conceived for a not-so-well-thought-out purpose has its good uses.

I have a tank. Sometimes I use it to drag cars out of the mud. Everyone should have a tank and use it.

If Perl::Critic would not be so tightly coupled to Perl Best Practices; if there were no emphasis on it being a tool to verify good coding standards; if it would just be taken as a tool to detect code patterns, as your described usage suggests - then it would be a great tool (it actually is in that sense). But its promoted usage is dangerous and bad practice.