Skip navigation

Category Archives: Uncategorized

Optimizing for the developer, not the user.

Mr. Lester, as usual, with the good stuff. While the example he’s using is PHP, it seems people didn’t understand that the point was in general, so there’s a follow up.

stackoverflow.com

I was planning on coming into the office early this morning, but just before I was going to leave, I read Spolsky’s post and in under a minute found a Perl::Critic related question I felt needed a good answer.

Dang, writing good answers takes time.

Managing perl

(The lowercase “p” perl is what I mean in the title.)

There’s a great new page on the Perl 5 wiki about administering your perl installation. It includes quite a number of things I believe in. Some of the more significant bits:

First and foremost thing I can say is if you depend heavily on Perl (or any single piece of technology) build it yourself. This will allow you finer control and faster upgrades than your OS vendor can. Windows is the exception, Strawberry Perl does a much better job packaging Perl and tweaking it for Windows than you can (and if you think you can better, please contribute to Strawberry).

This is especially true on Red Hat. Ignoring general management issues, you really ought to have a threaded and a non-threaded perl so that single-threaded code doesn’t pay the overhead for threads.

Fourth, keep up to date. This means keeping CPAN modules and perl itself at or near the latest versions. This will incur the occasional breakage as you encounter either intermittent bugs in new versions of CPAN modules, or API changes, or project code that accidentally depends on certain versions of CPAN modules. But it’s worth it, because the farther you fall behind the harder it becomes to catch up. As your perl gets older and older, fewer and fewer CPAN modules will work requiring more and more patching to get them working. As your CPAN modules get older, it will require a greater leap to bring them up to date, and more upgrades simultaneously. The sudden upgrade will cause many bugs to happen simultaneously making them take far more time and effort to track down then if they could be dealt with individually. Large upgrades require large effort, time and risks. Small upgrades require small effort, time and risks. The looming risk of a large upgrade will make developers settle for an older, buggier, less capable version and write a work around rather than risk the upgrade. This creates a hidden drag on your project and creates more and more complex code to maintain.

Another point: when you discover a bug in a CPAN module, there may be a fix for it, but if you’re very out of date with it, it may cause significant problems with other modules, making your upgrade of that one module really painful.

At Barclay’s, it took me 7 months to upgrade them from perl 5.6 to 5.8 and the latest version of other modules. Way too long.

If you’ve got good test coverage, you should be able to easily find any problems with upgrades.

Names

A topic anyone who’s known my programming style for a while knows that this is one of my pet peeves. Why can’t people use understandable variable names?

I just got though producing a set of constants for FIX message types and fields. I hate abbreviations that come from outside the problem domain, i.e. that an end user wouldn’t understand. I hate abbreviations in general, but specifically for “number” because there’s three different common ones in use. FIX uses two of them, with no clear reason for the difference.

In the world of finance, “FX” is a reasonable abbreviation to use in names, because the end users understand what it means. In FIX, there’s a field called “DKReason”; care to guess what “DK” stands for? If you said you “don’t know”, you’re correct. Yes, it literally stands for “don’t know”. The description for the field is “Reason for execution rejection.”, but if you’re reading through unfamiliar code and see “DKReason”, how the hell are you expected to understand the significance without hours of digging?

Crud. CPAN::Site is unfixably broken.

I’m setting up a DarkPAN at work.

CPAN::Site does most of what I want with maintaining it. Unfortunately, it has some bugs with parsing module versions (in particular Test::Object, which is a blocker for PPI); in particular, it can’t distinguish between namespace declarations in actual code and in code examples in documentation. I thought that it could be worked around, but in reading source, it’s doing some pretty incredible stuff.

It’s reading perl code straight out of raw tar files. It ungzips the tarballs, but doesn’t untar them. It simply tries to find perl code in the middle of the tar stream and grab the versions out that. Yech.

So, looks like I’m going to be forced to go back to CPAN::Mini::Inject, taking advantage of parse_version() in ExtUtils::MakeMaker. I’m going to have to have a look at brian d foy’s MyCPAN::Indexer work.

Perl::Critic policies in the DarkPAN.

I’m curious about any people who’ve written custom Perl::Critic policies that aren’t on CPAN.

What sorts of things are these for?

Have you had a look at Perl::Critic 1.082? Have you read Perl::Critic::DEVELOPER? What do you think?

This post originally appeared at use.perl.org.

The single most useful perlcritic command-line option.

For me, it’s --single-policy.

Generally, Perl::Critic is being used indirectly via a test using Test::P::C or Test::P::C::Progressive, with a perlcriticrc file that is in the distribution’s t/ directory.

The most common reason I have for running perlcritic is when there’s a Test::P::C::Progressive failure. In that case, I’m looking for violations of an individual policy to fix to get the violation count down.

--single-policy overrides all other selection criteria for policies. Its value, like the ones for the --include and --exclude options, is used as a regex applied against policy names with the /i, /m, and /x options applied to it. So, for example, if I want to scan for violations of Modules::RequireNoMatchVarsWithUseEnglish in the current directory, I can simply say

perlcritic --single-policy english .

When cleaning up a body of code, I find it easier to fix one kind of problem at a time in a bunch of files, rather than fixing all kinds of problems a single file at a time.

This post originally appeared at use.perl.org.

Writing configurable Perl::Critic Policies.

As of Perl::Critic 1.07, I would like to discourage the creation of constructors for Policies. Instead, I would encourage the use of P::C::Policy::initialize_if_enabled(). The reasoning is twofold.

One, this allows initialization to be deferred to the point where we know that the policy is going to be used. P::C::PolicyFactory always instantiates every Policy that it can find. It is up to the P::C::Config object to filter that set down. Primarily, this is an issue for Policies which dynamically load other modules.

Two, this method enables the Policy to decide for itself whether it should be enabled. This means that a Policy that depends upon a module that might not be present can remove itself from the set that violates() gets called on, thus speeding things up because it isn’t being called on every PPI::Element.

This originated from Chris Dolan’s work on the Perl Foundation grant to create the remaining Policies that can be implemented that enforce one of the ideas in PBP. Specifically, for Documentation::PodSpelling, but this change has been made to all the configurable core Policies. In particular, this helps CodeLayout::RequireTidyCode.

Differences from a constructor other than the obvious first parameter:

  1. The configuration is passed in as a hashref and not a hash an instance of Perl::Critic::PolicyConfig (corrected 2009/5/16).
  2. initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.

This is how the two above policies bow out.

This post originally appeared at use.perl.org.

Lesson of the day: Readonly, Exporter, and subroutine sigils

They don’t get along.

As of the recent 1.07 release, Perl::Critic, has started using Readonly to be more more self-compliant with Perl Best Practices. We had been avoiding use of constant for the reasons described in the book, but had not been willing to add the Readonly dependency until now.

The Perl::Critic coding standard has been to use sigils for subroutines in @EXPORT_OK, etc. and import lists, but Exporter treats them as optional. And, in fact, there’s code that strips them off (line 47 in v5.58). I haven’t figured out the commonality, but in a few environments, this fails spectacularly. Once we removed the subroutine sigils from everywhere, the problems have gone.

Explicitness: 0, Keyboard laziness: 1.

This post originally appeared at use.perl.org.