5 minimums for any perl script?

[Smylers]

David Cantrell writes:

> 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,

Hmmm, I'm not sure about that.

> and you want to get the only copy of your work-in-progress off your
> personal desktop if only so it gets backed up.

If you're somewhere that already has nightly back-ups then I think I'd
prefer not to have end-of-day-regardless-how-broken commits (and pushes
as well, if you're using Git or something where a commit is only local
anyway).

Mainly because allowing broken end-of-day commits makes it seem OK for
the dev branch to be broken. Which can make people care less about their
quality of commits overall. Whereas if the policy is 'you aren't ever
supposed to break the dev branch' it's easier to get a culture of people
thinking more carefully about their commits.

Note I'm not saying 'never commit work in progress'. There's plenty of
sorts of work in progress that can be committed:

* Adding a new function to a library or method to a class can be
  committed, even if nothing (committed) uses is yet. In fact,
  _especially_ if nothing uses it yet, cos it means the function or
  method doesn't have to be finished, or even work, so long as the
  module still compiles.

* Adding a new web page, however incomplete, if nothing else links to
  it.

* New tests can be committed, marked TODO if the functionality they test
  isn't ready to be committed yet.

* Incidental small fixes, doc patches, and minor enhancements that you
  happen to spot while working on the main code can be committed. (git
  commit -p is great for this kind of thing.)

* If adding a feature involves re-arranging some existing code in order
  to prise it open and create a place where it can be added, split this
  into first doing the refactoring, and commit that.
  
  The functionality will be unchanged; at that point the code may be
  needlessly long-winded or over-engineered for what it currently does,
  but your commit message can explain why you've done it and if it is
  supposed to function identically then it's easier for a colleague to
  review you haven't inadvertently changed something when that's the
  only thing in the commit.

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

True. I used to do Perl training, and the introductory Perl course
included a section on Cpan. As well as some exercises involving modules
I knew about, people were also encouraged to search for something which
could help in their current project -- which at one client meant
somebody searching for 'Cisco'. He couldn't've been more delighted to
discover Cisco::CopyConfig, a very niche module that I certainly hadn't
encountered before.

He wasn't actually a developer but a network administrator, and had come
on the course in the hope of picking up enough Perl so he'd be able to
automate one specific task: copying configs between Cisco devices. That
afternoon he was able to knock together a program he'd been expecting
would take him weeks to write, and was my equal-happiest[*1] course
participant ever, completely amazed that Perl would have a free library
already available to do something so specific.

And I was particularly relieved: the client was a mortgage provider, and
by co-incidence happened to own more of my own home than I did, so the
potential consequences of the course going badly seemed rather more
drastic than usual ...

I was actually trying to use "common" above in the sense of 'something
you have in common with other organizations', as distinct from things
specific to your business. My apologies for not expressing what I meant
more clearly.

Cheers

Smylers

[*1] I'm not prepared to disclose in public what I did for my other
equal-happiest course attendee, but feel free to ask me face-to-face
sometime.