5 minimums for any perl script?

David Cantrell david at cantrell.org.uk
Thu Feb 2 16:43:57 GMT 2012


On Thu, Feb 02, 2012 at 02:57:35PM +0000, Smylers wrote:

>   1 Make lots of small commits, one for each separable bug, feature,
>     refactoring, or whatever, and clearly described as much: make a
>     commit whenever you have something which is an unambiguous
>     improvement on the previous state, however small. ("Unambiguous" cos
>     if adding a feature has temporarily broken a different one, that's
>     not an improvement to somebody using the other feature; don't commit
>     till you've sorted it out.)

But do commit at the end of the day, even if it's still broken.  It's OK
to break your dev branches usually, and you want to get the only copy of
your work-in-progress off your personal desktop if only so it gets
backed up.

>   2 Look on Cpan for everything.
>   
>     If you think a task is in any way common or might have been done
>     before, check Cpan.

s/If you think.*before,//

There's plenty of *un*common things on the CPAN too.  Some are rubbish,
of course, but others are maintained by weirdo obsessives who have
spent years agonising over the edge-cases.

>                         Bother to install Cpan modules even for fairly
>     small things which might not seem worth the hassle of installing a
>     module -- because doing so means the module is then installed and
>     available for use by other programs you write in the future too, and
>     collectively it is worth it.

But do remember to list it as a dependency and make sure that you add it
to whatever you use for automagically installing dependencies when you
deploy a new version of the code, or add a new developer to your team.

Think about how you'll cope with future versions of modules changing
their behaviour - this could be as a bug fix, or as a new bug, or
deprecating old behaviour which the author has decided to no longer
support, or ...

-- 
David Cantrell | A machine for turning tea into grumpiness

    It's my experience that neither users nor customers can articulate
    what it is they want, nor can they evaluate it when they see it
        -- Alan Cooper


More information about the london.pm mailing list