Re: Writing TIMTOWDI-friendly CPAN Modules

Re writing CPAN modules, see:

Re Perl coding guidelines, I suggest you take a look at these, then make up your own mind:

Perl Style section of the Camel. perldoc perlstyle.
PBP and Perl::Critic.
Abigail Perl coding guidelines
Alias Perl coding guidelines
slash Perl coding guidelines
Daniel Allen Perl coding guidelines
bbc coding guidelines
p5ee portability coding guidelines
skud perl.com article on Perl coding standards

Update: Before releasing your first CPAN module, choose a module name and design an interface based on the general references above and on your own ideas, then post it here or on the module-authors@perl.org mailing list, requesting feedback. It is vital to focus on interface early and to get it right first time, because once your module is released into the wild, any change you make to its interface will break your existing user's code (anything else can be easily fixed in later releases).

Comment on Re: Writing TIMTOWDI-friendly CPAN Modules

Replies are listed 'Best First'.
Re^2: Writing TIMTOWDI-friendly CPAN Modules by salva (Canon) on May 15, 2005 at 11:34 UTC
It is vital to focus on interface early and to get it right first time Well, I have found this is not always possible. Sometimes to find the best interface for a module you have to actually use it and also let others use it and give you feedback. I think it's better to just release the module as soon as possible clearly stating on the docs that the API could change.	[reply]
Re^3: Writing TIMTOWDI-friendly CPAN Modules by eyepopslikeamosquito (Archbishop) on May 15, 2005 at 12:31 UTC
By all means, state clearly that the interface could change. Given it's the OP's first CPAN module, however, he should certainly seek advice on a proposed interface, and especially on module name, before uploading. As for actually using the module to determine how good the interface is, that is one of the many benefits of test-driven development: each test is a first class user of the module's interface and the act of writing the tests often causes one to change the interface. An interface that is hard to test is often hard to use. Code that can be unit tested in isolation is well de-coupled. Writing tests early improves design and interface. The practicality of changing an interface depends on how widely the module is adopted. For example, because File::Find is so heavily used, it has become practically impossible to change its (unfortunate) interface ... well, until Perl 6 rolls out, that is.	[reply]