Lines Matching refs:module
3 perlmodstyle - Perl module style guide
12 While this document is intended to be useful to all module authors, it is
16 module, rather than those parts which are only seen by the module's
18 can be extrapolated and applied successfully to a module's internals.
51 Patch, extend or subclass an existing module where possible
96 Ensure your module works under C<use strict> and C<-w>
148 Include tests with your module
152 Choose a sensible and consistent version numbering scheme (X.YY is the common Perl module numbering…
160 Package the module using "make dist"
170 Try not to launch headlong into developing your module without spending
176 You may not even need to write the module. Check whether it's already
183 If an existing module B<almost> does what you want, consider writing a
184 patch, writing a subclass, or otherwise extending the existing module
195 Your module should have a clearly defined scope which is no longer than
196 a single sentence. Can your module be broken down into a family of
209 This means that if a developer only needs a module for the BAR standard,
214 Make sure you choose an appropriate name for your module early on. This
215 will help people find and remember your module, and make programming
216 with your module more intuitive.
218 When naming your module, consider the following:
224 Be descriptive (i.e. accurately describes the purpose of the module).
232 Reflect the functionality of the module, not the implementation.
237 hierarchy already exists under which you could place your module.
241 You should contact modules@perl.org to ask them about your module name
242 before publishing your module. You should also try to ask people who
243 are already familiar with the module's application domain and the CPAN
249 Considerations for module design and coding:
253 Your module may be object oriented (OO) or not, or it may have both kinds
309 Think carefully about whether OO is appropriate for your module.
311 difficult for the average module user to understand or use.
343 Don't require every module user to jump through the same hoops to achieve a
347 module, it's a sign that you should have made that behaviour a default.
383 arguments, any more arguments become hard for the module user to
384 remember, and hard for the module author to manage. If you want to add
410 Your module should run successfully under the strict pragma and should
411 run without generating any warnings. Your module should also handle
423 When your module encounters an error it should do one or more of:
443 C<croak()> only when your module absolutely cannot figure out what to
452 the Error module.
466 Your module should include documentation aimed at Perl developers.
476 A synopsis of the common uses of the module
480 The purpose, scope and target applications of your module
501 The level of detail in Perl module documentation generally goes from
505 DESCRIPTION should describe your module in broad terms, generally in
506 just a few paragraphs; more detail of the module's routines or methods,
510 Ideally, someone who's slightly familiar with your module should be able
515 The recommended order of sections in Perl module documentation is:
562 Your module should also include a README file describing the module and
595 software describing user-visible changes to your module, in terms
620 If you want to release a 'beta' or 'alpha' version of a module but
682 module -- a module which purports to be stable or which hopes to achieve wide
697 package. Tools exist to help you to build your module in a MakeMaker-friendly
702 Make sure that your module has a license, and that the full text of it
722 Your module will be part of a developer's toolkit. It will not, in
731 a moderate understanding of your module's application domain, who's just
732 downloaded your module and wants to start using it as quickly as possible.
735 appropriate in a module's main documentation. If you really want to
750 How to create a new module
770 Perl Authors Upload Server. Contains links to information for module