Perl tools for making code better

[Leitz]

I have bodies of code to maintain and improve. Using tests is a given, and TDD is a wonderful thing. I am still learning Perl culture, and would appreciate guidance on tools and processes.

My parameters are hopefully simple. I prefer clear and verbose code so I can understand it the next time I read it. When producing tools I prefer to stay as close to Core/StdLib Perl as possible. When working *with* tools, more options are open. For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid.

My current plan is a cycle of:

1. Write Tests
2. Kwalitee
3. Perl::Tidy
4. Perl::Critic

Repeating as necessary, or until I have to ship the code. Are there other tools to add to the mix? Better processes?

[Tux]

Have a look at Release::Checklist. The doc is an exposition of all (perl) tools to improve your perl module (and code).

All you stated yourself is already part of that doc :)

[Leitz]

Tux, excellent work; thanks! I'll be studying that.

[kcott]

G'day Leitz,

That's a great list from ++Tux. I also use the core module, ExtUtils::Manifest; typically like this:

#!perl

use strict;
use warnings;

use Test::More;

BEGIN {
    if (! $ENV{RELEASE_TESTING}) {
        plan skip_all => 'Author test: $ENV{RELEASE_TESTING} false.';
    }
}

use ExtUtils::Manifest qw{manicheck filecheck};

plan tests => 2;

is_deeply([manicheck()], [], 'Check files in "MANIFEST" exist.');
is_deeply([filecheck()], [], 'Check for files not in "MANIFEST" or "MA
+NIFEST.SKIP".');

I typically create modules using Module::Starter via module-starter with Module::Starter::PBP as a plugin.

"For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid."

If you're using, for example, Test::Perl::Critic for development but you're not shipping it, you will have to remove the test from your t/ directory and modify your MANIFEST file prior to running "make dist". You will need to do this for possibly quite a few similar tests. This would be tedious as well as being error-prone (easy to get the two versions out of sync). Consider using "... skip_all => 'Author test ..." as I showed in the code above.

There was some recent discussion about naming conventions for test files. You can see how I normally number these. For "Author tests", I have recently been adding 99- to the start of those (which I find makes it clear what they are). A listing of my t/ directory would typically include files like:

99-00_pod.t
99-01_pod_coverage.t
99-02_manifest.t

Do note that is what I choose to do. Others have their own conventions. Do not feel in any way compelled to follow what I do.

[eyepopslikeamosquito]

I maintain a list of links on this topic: Re: I need perl coding standards (Coding Standards References)