| 1 | .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32 |
| 2 | .\" |
| 3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
| 5 | .de Sh \" Subsection heading |
| 6 | .br |
| 7 | .if t .Sp |
| 8 | .ne 5 |
| 9 | .PP |
| 10 | \fB\\$1\fR |
| 11 | .PP |
| 12 | .. |
| 13 | .de Sp \" Vertical space (when we can't use .PP) |
| 14 | .if t .sp .5v |
| 15 | .if n .sp |
| 16 | .. |
| 17 | .de Vb \" Begin verbatim text |
| 18 | .ft CW |
| 19 | .nf |
| 20 | .ne \\$1 |
| 21 | .. |
| 22 | .de Ve \" End verbatim text |
| 23 | .ft R |
| 24 | .fi |
| 25 | .. |
| 26 | .\" Set up some character translations and predefined strings. \*(-- will |
| 27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 28 | .\" double quote, and \*(R" will give a right double quote. | will give a |
| 29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to |
| 30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' |
| 31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. |
| 32 | .tr \(*W-|\(bv\*(Tr |
| 33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 34 | .ie n \{\ |
| 35 | . ds -- \(*W- |
| 36 | . ds PI pi |
| 37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 39 | . ds L" "" |
| 40 | . ds R" "" |
| 41 | . ds C` "" |
| 42 | . ds C' "" |
| 43 | 'br\} |
| 44 | .el\{\ |
| 45 | . ds -- \|\(em\| |
| 46 | . ds PI \(*p |
| 47 | . ds L" `` |
| 48 | . ds R" '' |
| 49 | 'br\} |
| 50 | .\" |
| 51 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index |
| 53 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 54 | .\" output yourself in some meaningful fashion. |
| 55 | .if \nF \{\ |
| 56 | . de IX |
| 57 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 58 | .. |
| 59 | . nr % 0 |
| 60 | . rr F |
| 61 | .\} |
| 62 | .\" |
| 63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 64 | .\" way too many mistakes in technical documents. |
| 65 | .hy 0 |
| 66 | .if n .na |
| 67 | .\" |
| 68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 69 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 70 | . \" fudge factors for nroff and troff |
| 71 | .if n \{\ |
| 72 | . ds #H 0 |
| 73 | . ds #V .8m |
| 74 | . ds #F .3m |
| 75 | . ds #[ \f1 |
| 76 | . ds #] \fP |
| 77 | .\} |
| 78 | .if t \{\ |
| 79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 80 | . ds #V .6m |
| 81 | . ds #F 0 |
| 82 | . ds #[ \& |
| 83 | . ds #] \& |
| 84 | .\} |
| 85 | . \" simple accents for nroff and troff |
| 86 | .if n \{\ |
| 87 | . ds ' \& |
| 88 | . ds ` \& |
| 89 | . ds ^ \& |
| 90 | . ds , \& |
| 91 | . ds ~ ~ |
| 92 | . ds / |
| 93 | .\} |
| 94 | .if t \{\ |
| 95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 101 | .\} |
| 102 | . \" troff and (daisy-wheel) nroff accents |
| 103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 110 | .ds ae a\h'-(\w'a'u*4/10)'e |
| 111 | .ds Ae A\h'-(\w'A'u*4/10)'E |
| 112 | . \" corrections for vroff |
| 113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 115 | . \" for low resolution devices (crt and lpr) |
| 116 | .if \n(.H>23 .if \n(.V>19 \ |
| 117 | \{\ |
| 118 | . ds : e |
| 119 | . ds 8 ss |
| 120 | . ds o a |
| 121 | . ds d- d\h'-1'\(ga |
| 122 | . ds D- D\h'-1'\(hy |
| 123 | . ds th \o'bp' |
| 124 | . ds Th \o'LP' |
| 125 | . ds ae ae |
| 126 | . ds Ae AE |
| 127 | .\} |
| 128 | .rm #[ #] #H #V #F C |
| 129 | .\" ======================================================================== |
| 130 | .\" |
| 131 | .IX Title "PERLMODSTYLE 1" |
| 132 | .TH PERLMODSTYLE 1 "2006-01-07" "perl v5.8.8" "Perl Programmers Reference Guide" |
| 133 | .SH "NAME" |
| 134 | perlmodstyle \- Perl module style guide |
| 135 | .SH "INTRODUCTION" |
| 136 | .IX Header "INTRODUCTION" |
| 137 | This document attempts to describe the Perl Community's \*(L"best practice\*(R" |
| 138 | for writing Perl modules. It extends the recommendations found in |
| 139 | perlstyle , which should be considered required reading |
| 140 | before reading this document. |
| 141 | .PP |
| 142 | While this document is intended to be useful to all module authors, it is |
| 143 | particularly aimed at authors who wish to publish their modules on \s-1CPAN\s0. |
| 144 | .PP |
| 145 | The focus is on elements of style which are visible to the users of a |
| 146 | module, rather than those parts which are only seen by the module's |
| 147 | developers. However, many of the guidelines presented in this document |
| 148 | can be extrapolated and applied successfully to a module's internals. |
| 149 | .PP |
| 150 | This document differs from perlnewmod in that it is a style guide |
| 151 | rather than a tutorial on creating \s-1CPAN\s0 modules. It provides a |
| 152 | checklist against which modules can be compared to determine whether |
| 153 | they conform to best practice, without necessarily describing in detail |
| 154 | how to achieve this. |
| 155 | .PP |
| 156 | All the advice contained in this document has been gleaned from |
| 157 | extensive conversations with experienced \s-1CPAN\s0 authors and users. Every |
| 158 | piece of advice given here is the result of previous mistakes. This |
| 159 | information is here to help you avoid the same mistakes and the extra |
| 160 | work that would inevitably be required to fix them. |
| 161 | .PP |
| 162 | The first section of this document provides an itemized checklist; |
| 163 | subsequent sections provide a more detailed discussion of the items on |
| 164 | the list. The final section, \*(L"Common Pitfalls\*(R", describes some of the |
| 165 | most popular mistakes made by \s-1CPAN\s0 authors. |
| 166 | .SH "QUICK CHECKLIST" |
| 167 | .IX Header "QUICK CHECKLIST" |
| 168 | For more detail on each item in this checklist, see below. |
| 169 | .Sh "Before you start" |
| 170 | .IX Subsection "Before you start" |
| 171 | .IP "\(bu" 4 |
| 172 | Don't re-invent the wheel |
| 173 | .IP "\(bu" 4 |
| 174 | Patch, extend or subclass an existing module where possible |
| 175 | .IP "\(bu" 4 |
| 176 | Do one thing and do it well |
| 177 | .IP "\(bu" 4 |
| 178 | Choose an appropriate name |
| 179 | .Sh "The \s-1API\s0" |
| 180 | .IX Subsection "The API" |
| 181 | .IP "\(bu" 4 |
| 182 | \&\s-1API\s0 should be understandable by the average programmer |
| 183 | .IP "\(bu" 4 |
| 184 | Simple methods for simple tasks |
| 185 | .IP "\(bu" 4 |
| 186 | Separate functionality from output |
| 187 | .IP "\(bu" 4 |
| 188 | Consistent naming of subroutines or methods |
| 189 | .IP "\(bu" 4 |
| 190 | Use named parameters (a hash or hashref) when there are more than two |
| 191 | parameters |
| 192 | .Sh "Stability" |
| 193 | .IX Subsection "Stability" |
| 194 | .IP "\(bu" 4 |
| 195 | Ensure your module works under \f(CW\*(C`use strict\*(C'\fR and \f(CW\*(C`\-w\*(C'\fR |
| 196 | .IP "\(bu" 4 |
| 197 | Stable modules should maintain backwards compatibility |
| 198 | .Sh "Documentation" |
| 199 | .IX Subsection "Documentation" |
| 200 | .IP "\(bu" 4 |
| 201 | Write documentation in \s-1POD\s0 |
| 202 | .IP "\(bu" 4 |
| 203 | Document purpose, scope and target applications |
| 204 | .IP "\(bu" 4 |
| 205 | Document each publically accessible method or subroutine, including params and return values |
| 206 | .IP "\(bu" 4 |
| 207 | Give examples of use in your documentation |
| 208 | .IP "\(bu" 4 |
| 209 | Provide a \s-1README\s0 file and perhaps also release notes, changelog, etc |
| 210 | .IP "\(bu" 4 |
| 211 | Provide links to further information (\s-1URL\s0, email) |
| 212 | .Sh "Release considerations" |
| 213 | .IX Subsection "Release considerations" |
| 214 | .IP "\(bu" 4 |
| 215 | Specify pre-requisites in Makefile.PL or Build.PL |
| 216 | .IP "\(bu" 4 |
| 217 | Specify Perl version requirements with \f(CW\*(C`use\*(C'\fR |
| 218 | .IP "\(bu" 4 |
| 219 | Include tests with your module |
| 220 | .IP "\(bu" 4 |
| 221 | Choose a sensible and consistent version numbering scheme (X.YY is the common Perl module numbering scheme) |
| 222 | .IP "\(bu" 4 |
| 223 | Increment the version number for every change, no matter how small |
| 224 | .IP "\(bu" 4 |
| 225 | Package the module using \*(L"make dist\*(R" |
| 226 | .IP "\(bu" 4 |
| 227 | Choose an appropriate license (GPL/Artistic is a good default) |
| 228 | .SH "BEFORE YOU START WRITING A MODULE" |
| 229 | .IX Header "BEFORE YOU START WRITING A MODULE" |
| 230 | Try not to launch headlong into developing your module without spending |
| 231 | some time thinking first. A little forethought may save you a vast |
| 232 | amount of effort later on. |
| 233 | .Sh "Has it been done before?" |
| 234 | .IX Subsection "Has it been done before?" |
| 235 | You may not even need to write the module. Check whether it's already |
| 236 | been done in Perl, and avoid re-inventing the wheel unless you have a |
| 237 | good reason. |
| 238 | .PP |
| 239 | Good places to look for pre-existing modules include |
| 240 | http://search.cpan.org/ and asking on modules@perl.org |
| 241 | .PP |
| 242 | If an existing module \fBalmost\fR does what you want, consider writing a |
| 243 | patch, writing a subclass, or otherwise extending the existing module |
| 244 | rather than rewriting it. |
| 245 | .Sh "Do one thing and do it well" |
| 246 | .IX Subsection "Do one thing and do it well" |
| 247 | At the risk of stating the obvious, modules are intended to be modular. |
| 248 | A Perl developer should be able to use modules to put together the |
| 249 | building blocks of their application. However, it's important that the |
| 250 | blocks are the right shape, and that the developer shouldn't have to use |
| 251 | a big block when all they need is a small one. |
| 252 | .PP |
| 253 | Your module should have a clearly defined scope which is no longer than |
| 254 | a single sentence. Can your module be broken down into a family of |
| 255 | related modules? |
| 256 | .PP |
| 257 | Bad example: |
| 258 | .PP |
| 259 | \&\*(L"FooBar.pm provides an implementation of the \s-1FOO\s0 protocol and the |
| 260 | related \s-1BAR\s0 standard.\*(R" |
| 261 | .PP |
| 262 | Good example: |
| 263 | .PP |
| 264 | \&\*(L"Foo.pm provides an implementation of the \s-1FOO\s0 protocol. Bar.pm |
| 265 | implements the related \s-1BAR\s0 protocol.\*(R" |
| 266 | .PP |
| 267 | This means that if a developer only needs a module for the \s-1BAR\s0 standard, |
| 268 | they should not be forced to install libraries for \s-1FOO\s0 as well. |
| 269 | .Sh "What's in a name?" |
| 270 | .IX Subsection "What's in a name?" |
| 271 | Make sure you choose an appropriate name for your module early on. This |
| 272 | will help people find and remember your module, and make programming |
| 273 | with your module more intuitive. |
| 274 | .PP |
| 275 | When naming your module, consider the following: |
| 276 | .IP "\(bu" 4 |
| 277 | Be descriptive (i.e. accurately describes the purpose of the module). |
| 278 | .IP "\(bu" 4 |
| 279 | Be consistent with existing modules. |
| 280 | .IP "\(bu" 4 |
| 281 | Reflect the functionality of the module, not the implementation. |
| 282 | .IP "\(bu" 4 |
| 283 | Avoid starting a new top-level hierarchy, especially if a suitable |
| 284 | hierarchy already exists under which you could place your module. |
| 285 | .PP |
| 286 | You should contact modules@perl.org to ask them about your module name |
| 287 | before publishing your module. You should also try to ask people who |
| 288 | are already familiar with the module's application domain and the \s-1CPAN\s0 |
| 289 | naming system. Authors of similar modules, or modules with similar |
| 290 | names, may be a good place to start. |
| 291 | .SH "DESIGNING AND WRITING YOUR MODULE" |
| 292 | .IX Header "DESIGNING AND WRITING YOUR MODULE" |
| 293 | Considerations for module design and coding: |
| 294 | .Sh "To \s-1OO\s0 or not to \s-1OO\s0?" |
| 295 | .IX Subsection "To OO or not to OO?" |
| 296 | Your module may be object oriented (\s-1OO\s0) or not, or it may have both kinds |
| 297 | of interfaces available. There are pros and cons of each technique, which |
| 298 | should be considered when you design your \s-1API\s0. |
| 299 | .PP |
| 300 | According to Damian Conway, you should consider using \s-1OO:\s0 |
| 301 | .IP "\(bu" 4 |
| 302 | When the system is large or likely to become so |
| 303 | .IP "\(bu" 4 |
| 304 | When the data is aggregated in obvious structures that will become objects |
| 305 | .IP "\(bu" 4 |
| 306 | When the types of data form a natural hierarchy that can make use of inheritance |
| 307 | .IP "\(bu" 4 |
| 308 | When operations on data vary according to data type (making |
| 309 | polymorphic invocation of methods feasible) |
| 310 | .IP "\(bu" 4 |
| 311 | When it is likely that new data types may be later introduced |
| 312 | into the system, and will need to be handled by existing code |
| 313 | .IP "\(bu" 4 |
| 314 | When interactions between data are best represented by |
| 315 | overloaded operators |
| 316 | .IP "\(bu" 4 |
| 317 | When the implementation of system components is likely to |
| 318 | change over time (and hence should be encapsulated) |
| 319 | .IP "\(bu" 4 |
| 320 | When the system design is itself object-oriented |
| 321 | .IP "\(bu" 4 |
| 322 | When large amounts of client code will use the software (and |
| 323 | should be insulated from changes in its implementation) |
| 324 | .IP "\(bu" 4 |
| 325 | When many separate operations will need to be applied to the |
| 326 | same set of data |
| 327 | .PP |
| 328 | Think carefully about whether \s-1OO\s0 is appropriate for your module. |
| 329 | Gratuitous object orientation results in complex APIs which are |
| 330 | difficult for the average module user to understand or use. |
| 331 | .Sh "Designing your \s-1API\s0" |
| 332 | .IX Subsection "Designing your API" |
| 333 | Your interfaces should be understandable by an average Perl programmer. |
| 334 | The following guidelines may help you judge whether your \s-1API\s0 is |
| 335 | sufficiently straightforward: |
| 336 | .IP "Write simple routines to do simple things." 4 |
| 337 | .IX Item "Write simple routines to do simple things." |
| 338 | It's better to have numerous simple routines than a few monolithic ones. |
| 339 | If your routine changes its behaviour significantly based on its |
| 340 | arguments, it's a sign that you should have two (or more) separate |
| 341 | routines. |
| 342 | .IP "Separate functionality from output." 4 |
| 343 | .IX Item "Separate functionality from output." |
| 344 | Return your results in the most generic form possible and allow the user |
| 345 | to choose how to use them. The most generic form possible is usually a |
| 346 | Perl data structure which can then be used to generate a text report, |
| 347 | \&\s-1HTML\s0, \s-1XML\s0, a database query, or whatever else your users require. |
| 348 | .Sp |
| 349 | If your routine iterates through some kind of list (such as a list of |
| 350 | files, or records in a database) you may consider providing a callback |
| 351 | so that users can manipulate each element of the list in turn. |
| 352 | File::Find provides an example of this with its |
| 353 | \&\f(CW\*(C`find(\e&wanted, $dir)\*(C'\fR syntax. |
| 354 | .IP "Provide sensible shortcuts and defaults." 4 |
| 355 | .IX Item "Provide sensible shortcuts and defaults." |
| 356 | Don't require every module user to jump through the same hoops to achieve a |
| 357 | simple result. You can always include optional parameters or routines for |
| 358 | more complex or non-standard behaviour. If most of your users have to |
| 359 | type a few almost identical lines of code when they start using your |
| 360 | module, it's a sign that you should have made that behaviour a default. |
| 361 | Another good indicator that you should use defaults is if most of your |
| 362 | users call your routines with the same arguments. |
| 363 | .IP "Naming conventions" 4 |
| 364 | .IX Item "Naming conventions" |
| 365 | Your naming should be consistent. For instance, it's better to have: |
| 366 | .Sp |
| 367 | .Vb 3 |
| 368 | \& display_day(); |
| 369 | \& display_week(); |
| 370 | \& display_year(); |
| 371 | .Ve |
| 372 | .Sp |
| 373 | than |
| 374 | .Sp |
| 375 | .Vb 3 |
| 376 | \& display_day(); |
| 377 | \& week_display(); |
| 378 | \& show_year(); |
| 379 | .Ve |
| 380 | .Sp |
| 381 | This applies equally to method names, parameter names, and anything else |
| 382 | which is visible to the user (and most things that aren't!) |
| 383 | .IP "Parameter passing" 4 |
| 384 | .IX Item "Parameter passing" |
| 385 | Use named parameters. It's easier to use a hash like this: |
| 386 | .Sp |
| 387 | .Vb 5 |
| 388 | \& $obj->do_something( |
| 389 | \& name => "wibble", |
| 390 | \& type => "text", |
| 391 | \& size => 1024, |
| 392 | \& ); |
| 393 | .Ve |
| 394 | .Sp |
| 395 | \&... than to have a long list of unnamed parameters like this: |
| 396 | .Sp |
| 397 | .Vb 1 |
| 398 | \& $obj->do_something("wibble", "text", 1024); |
| 399 | .Ve |
| 400 | .Sp |
| 401 | While the list of arguments might work fine for one, two or even three |
| 402 | arguments, any more arguments become hard for the module user to |
| 403 | remember, and hard for the module author to manage. If you want to add |
| 404 | a new parameter you will have to add it to the end of the list for |
| 405 | backward compatibility, and this will probably make your list order |
| 406 | unintuitive. Also, if many elements may be undefined you may see the |
| 407 | following unattractive method calls: |
| 408 | .Sp |
| 409 | .Vb 1 |
| 410 | \& $obj->do_something(undef, undef, undef, undef, undef, undef, 1024); |
| 411 | .Ve |
| 412 | .Sp |
| 413 | Provide sensible defaults for parameters which have them. Don't make |
| 414 | your users specify parameters which will almost always be the same. |
| 415 | .Sp |
| 416 | The issue of whether to pass the arguments in a hash or a hashref is |
| 417 | largely a matter of personal style. |
| 418 | .Sp |
| 419 | The use of hash keys starting with a hyphen (\f(CW\*(C`\-name\*(C'\fR) or entirely in |
| 420 | upper case (\f(CW\*(C`NAME\*(C'\fR) is a relic of older versions of Perl in which |
| 421 | ordinary lower case strings were not handled correctly by the \f(CW\*(C`=>\*(C'\fR |
| 422 | operator. While some modules retain uppercase or hyphenated argument |
| 423 | keys for historical reasons or as a matter of personal style, most new |
| 424 | modules should use simple lower case keys. Whatever you choose, be |
| 425 | consistent! |
| 426 | .Sh "Strictness and warnings" |
| 427 | .IX Subsection "Strictness and warnings" |
| 428 | Your module should run successfully under the strict pragma and should |
| 429 | run without generating any warnings. Your module should also handle |
| 430 | taint-checking where appropriate, though this can cause difficulties in |
| 431 | many cases. |
| 432 | .Sh "Backwards compatibility" |
| 433 | .IX Subsection "Backwards compatibility" |
| 434 | Modules which are \*(L"stable\*(R" should not break backwards compatibility |
| 435 | without at least a long transition phase and a major change in version |
| 436 | number. |
| 437 | .Sh "Error handling and messages" |
| 438 | .IX Subsection "Error handling and messages" |
| 439 | When your module encounters an error it should do one or more of: |
| 440 | .IP "\(bu" 4 |
| 441 | Return an undefined value. |
| 442 | .IP "\(bu" 4 |
| 443 | set \f(CW$Module::errstr\fR or similar (\f(CW\*(C`errstr\*(C'\fR is a common name used by |
| 444 | \&\s-1DBI\s0 and other popular modules; if you choose something else, be sure to |
| 445 | document it clearly). |
| 446 | .IP "\(bu" 4 |
| 447 | \&\f(CW\*(C`warn()\*(C'\fR or \f(CW\*(C`carp()\*(C'\fR a message to \s-1STDERR\s0. |
| 448 | .IP "\(bu" 4 |
| 449 | \&\f(CW\*(C`croak()\*(C'\fR only when your module absolutely cannot figure out what to |
| 450 | do. (\f(CW\*(C`croak()\*(C'\fR is a better version of \f(CW\*(C`die()\*(C'\fR for use within |
| 451 | modules, which reports its errors from the perspective of the caller. |
| 452 | See Carp for details of \f(CW\*(C`croak()\*(C'\fR, \f(CW\*(C`carp()\*(C'\fR and other useful |
| 453 | routines.) |
| 454 | .IP "\(bu" 4 |
| 455 | As an alternative to the above, you may prefer to throw exceptions using |
| 456 | the Error module. |
| 457 | .PP |
| 458 | Configurable error handling can be very useful to your users. Consider |
| 459 | offering a choice of levels for warning and debug messages, an option to |
| 460 | send messages to a separate file, a way to specify an error-handling |
| 461 | routine, or other such features. Be sure to default all these options |
| 462 | to the commonest use. |
| 463 | .SH "DOCUMENTING YOUR MODULE" |
| 464 | .IX Header "DOCUMENTING YOUR MODULE" |
| 465 | .Sh "\s-1POD\s0" |
| 466 | .IX Subsection "POD" |
| 467 | Your module should include documentation aimed at Perl developers. |
| 468 | You should use Perl's \*(L"plain old documentation\*(R" (\s-1POD\s0) for your general |
| 469 | technical documentation, though you may wish to write additional |
| 470 | documentation (white papers, tutorials, etc) in some other format. |
| 471 | You need to cover the following subjects: |
| 472 | .IP "\(bu" 4 |
| 473 | A synopsis of the common uses of the module |
| 474 | .IP "\(bu" 4 |
| 475 | The purpose, scope and target applications of your module |
| 476 | .IP "\(bu" 4 |
| 477 | Use of each publically accessible method or subroutine, including |
| 478 | parameters and return values |
| 479 | .IP "\(bu" 4 |
| 480 | Examples of use |
| 481 | .IP "\(bu" 4 |
| 482 | Sources of further information |
| 483 | .IP "\(bu" 4 |
| 484 | A contact email address for the author/maintainer |
| 485 | .PP |
| 486 | The level of detail in Perl module documentation generally goes from |
| 487 | less detailed to more detailed. Your \s-1SYNOPSIS\s0 section should contain a |
| 488 | minimal example of use (perhaps as little as one line of code; skip the |
| 489 | unusual use cases or anything not needed by most users); the |
| 490 | \&\s-1DESCRIPTION\s0 should describe your module in broad terms, generally in |
| 491 | just a few paragraphs; more detail of the module's routines or methods, |
| 492 | lengthy code examples, or other in-depth material should be given in |
| 493 | subsequent sections. |
| 494 | .PP |
| 495 | Ideally, someone who's slightly familiar with your module should be able |
| 496 | to refresh their memory without hitting \*(L"page down\*(R". As your reader |
| 497 | continues through the document, they should receive a progressively |
| 498 | greater amount of knowledge. |
| 499 | .PP |
| 500 | The recommended order of sections in Perl module documentation is: |
| 501 | .IP "\(bu" 4 |
| 502 | \&\s-1NAME\s0 |
| 503 | .IP "\(bu" 4 |
| 504 | \&\s-1SYNOPSIS\s0 |
| 505 | .IP "\(bu" 4 |
| 506 | \&\s-1DESCRIPTION\s0 |
| 507 | .IP "\(bu" 4 |
| 508 | One or more sections or subsections giving greater detail of available |
| 509 | methods and routines and any other relevant information. |
| 510 | .IP "\(bu" 4 |
| 511 | BUGS/CAVEATS/etc |
| 512 | .IP "\(bu" 4 |
| 513 | \&\s-1AUTHOR\s0 |
| 514 | .IP "\(bu" 4 |
| 515 | \&\s-1SEE\s0 \s-1ALSO\s0 |
| 516 | .IP "\(bu" 4 |
| 517 | \&\s-1COPYRIGHT\s0 and \s-1LICENSE\s0 |
| 518 | .PP |
| 519 | Keep your documentation near the code it documents (\*(L"inline\*(R" |
| 520 | documentation). Include \s-1POD\s0 for a given method right above that |
| 521 | method's subroutine. This makes it easier to keep the documentation up |
| 522 | to date, and avoids having to document each piece of code twice (once in |
| 523 | \&\s-1POD\s0 and once in comments). |
| 524 | .Sh "\s-1README\s0, \s-1INSTALL\s0, release notes, changelogs" |
| 525 | .IX Subsection "README, INSTALL, release notes, changelogs" |
| 526 | Your module should also include a \s-1README\s0 file describing the module and |
| 527 | giving pointers to further information (website, author email). |
| 528 | .PP |
| 529 | An \s-1INSTALL\s0 file should be included, and should contain simple installation |
| 530 | instructions. When using ExtUtils::MakeMaker this will usually be: |
| 531 | .IP "perl Makefile.PL" 4 |
| 532 | .IX Item "perl Makefile.PL" |
| 533 | .PD 0 |
| 534 | .IP "make" 4 |
| 535 | .IX Item "make" |
| 536 | .IP "make test" 4 |
| 537 | .IX Item "make test" |
| 538 | .IP "make install" 4 |
| 539 | .IX Item "make install" |
| 540 | .PD |
| 541 | .PP |
| 542 | When using Module::Build, this will usually be: |
| 543 | .IP "perl Build.PL" 4 |
| 544 | .IX Item "perl Build.PL" |
| 545 | .PD 0 |
| 546 | .IP "perl Build" 4 |
| 547 | .IX Item "perl Build" |
| 548 | .IP "perl Build test" 4 |
| 549 | .IX Item "perl Build test" |
| 550 | .IP "perl Build install" 4 |
| 551 | .IX Item "perl Build install" |
| 552 | .PD |
| 553 | .PP |
| 554 | Release notes or changelogs should be produced for each release of your |
| 555 | software describing user-visible changes to your module, in terms |
| 556 | relevant to the user. |
| 557 | .SH "RELEASE CONSIDERATIONS" |
| 558 | .IX Header "RELEASE CONSIDERATIONS" |
| 559 | .Sh "Version numbering" |
| 560 | .IX Subsection "Version numbering" |
| 561 | Version numbers should indicate at least major and minor releases, and |
| 562 | possibly sub-minor releases. A major release is one in which most of |
| 563 | the functionality has changed, or in which major new functionality is |
| 564 | added. A minor release is one in which a small amount of functionality |
| 565 | has been added or changed. Sub-minor version numbers are usually used |
| 566 | for changes which do not affect functionality, such as documentation |
| 567 | patches. |
| 568 | .PP |
| 569 | The most common \s-1CPAN\s0 version numbering scheme looks like this: |
| 570 | .PP |
| 571 | .Vb 1 |
| 572 | \& 1.00, 1.10, 1.11, 1.20, 1.30, 1.31, 1.32 |
| 573 | .Ve |
| 574 | .PP |
| 575 | A correct \s-1CPAN\s0 version number is a floating point number with at least |
| 576 | 2 digits after the decimal. You can test whether it conforms to \s-1CPAN\s0 by |
| 577 | using |
| 578 | .PP |
| 579 | .Vb 1 |
| 580 | \& perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' 'Foo.pm' |
| 581 | .Ve |
| 582 | .PP |
| 583 | If you want to release a 'beta' or 'alpha' version of a module but |
| 584 | don't want \s-1CPAN\s0.pm to list it as most recent use an '_' after the |
| 585 | regular version number followed by at least 2 digits, eg. 1.20_01. If |
| 586 | you do this, the following idiom is recommended: |
| 587 | .PP |
| 588 | .Vb 3 |
| 589 | \& $VERSION = "1.12_01"; |
| 590 | \& $XS_VERSION = $VERSION; # only needed if you have XS code |
| 591 | \& $VERSION = eval $VERSION; |
| 592 | .Ve |
| 593 | .PP |
| 594 | With that trick MakeMaker will only read the first line and thus read |
| 595 | the underscore, while the perl interpreter will evaluate the \f(CW$VERSION\fR |
| 596 | and convert the string into a number. Later operations that treat |
| 597 | \&\f(CW$VERSION\fR as a number will then be able to do so without provoking a |
| 598 | warning about \f(CW$VERSION\fR not being a number. |
| 599 | .PP |
| 600 | Never release anything (even a one-word documentation patch) without |
| 601 | incrementing the number. Even a one-word documentation patch should |
| 602 | result in a change in version at the sub-minor level. |
| 603 | .Sh "Pre-requisites" |
| 604 | .IX Subsection "Pre-requisites" |
| 605 | Module authors should carefully consider whether to rely on other |
| 606 | modules, and which modules to rely on. |
| 607 | .PP |
| 608 | Most importantly, choose modules which are as stable as possible. In |
| 609 | order of preference: |
| 610 | .IP "\(bu" 4 |
| 611 | Core Perl modules |
| 612 | .IP "\(bu" 4 |
| 613 | Stable \s-1CPAN\s0 modules |
| 614 | .IP "\(bu" 4 |
| 615 | Unstable \s-1CPAN\s0 modules |
| 616 | .IP "\(bu" 4 |
| 617 | Modules not available from \s-1CPAN\s0 |
| 618 | .PP |
| 619 | Specify version requirements for other Perl modules in the |
| 620 | pre-requisites in your Makefile.PL or Build.PL. |
| 621 | .PP |
| 622 | Be sure to specify Perl version requirements both in Makefile.PL or |
| 623 | Build.PL and with \f(CW\*(C`require 5.6.1\*(C'\fR or similar. See the section on |
| 624 | \&\f(CW\*(C`use VERSION\*(C'\fR of \*(L"require\*(R" in perlfunc for details. |
| 625 | .Sh "Testing" |
| 626 | .IX Subsection "Testing" |
| 627 | All modules should be tested before distribution (using \*(L"make disttest\*(R"), |
| 628 | and the tests should also be available to people installing the modules |
| 629 | (using \*(L"make test\*(R"). |
| 630 | For Module::Build you would use the \f(CW\*(C`make test\*(C'\fR equivalent \f(CW\*(C`perl Build test\*(C'\fR. |
| 631 | .PP |
| 632 | The importance of these tests is proportional to the alleged stability of a |
| 633 | module \*(-- a module which purports to be stable or which hopes to achieve wide |
| 634 | use should adhere to as strict a testing regime as possible. |
| 635 | .PP |
| 636 | Useful modules to help you write tests (with minimum impact on your |
| 637 | development process or your time) include Test::Simple, Carp::Assert |
| 638 | and Test::Inline. |
| 639 | For more sophisticated test suites there are Test::More and Test::MockObject. |
| 640 | .Sh "Packaging" |
| 641 | .IX Subsection "Packaging" |
| 642 | Modules should be packaged using one of the standard packaging tools. |
| 643 | Currently you have the choice between ExtUtils::MakeMaker and the |
| 644 | more platform independent Module::Build, allowing modules to be installed in a |
| 645 | consistent manner. |
| 646 | When using ExtUtils::MakeMaker, you can use \*(L"make dist\*(R" to create your |
| 647 | package. Tools exist to help you to build your module in a MakeMaker-friendly |
| 648 | style. These include ExtUtils::ModuleMaker and h2xs. See also perlnewmod. |
| 649 | .Sh "Licensing" |
| 650 | .IX Subsection "Licensing" |
| 651 | Make sure that your module has a license, and that the full text of it |
| 652 | is included in the distribution (unless it's a common one and the terms |
| 653 | of the license don't require you to include it). |
| 654 | .PP |
| 655 | If you don't know what license to use, dual licensing under the \s-1GPL\s0 |
| 656 | and Artistic licenses (the same as Perl itself) is a good idea. |
| 657 | See perlgpl and perlartistic. |
| 658 | .SH "COMMON PITFALLS" |
| 659 | .IX Header "COMMON PITFALLS" |
| 660 | .Sh "Reinventing the wheel" |
| 661 | .IX Subsection "Reinventing the wheel" |
| 662 | There are certain application spaces which are already very, very well |
| 663 | served by \s-1CPAN\s0. One example is templating systems, another is date and |
| 664 | time modules, and there are many more. While it is a rite of passage to |
| 665 | write your own version of these things, please consider carefully |
| 666 | whether the Perl world really needs you to publish it. |
| 667 | .Sh "Trying to do too much" |
| 668 | .IX Subsection "Trying to do too much" |
| 669 | Your module will be part of a developer's toolkit. It will not, in |
| 670 | itself, form the \fBentire\fR toolkit. It's tempting to add extra features |
| 671 | until your code is a monolithic system rather than a set of modular |
| 672 | building blocks. |
| 673 | .Sh "Inappropriate documentation" |
| 674 | .IX Subsection "Inappropriate documentation" |
| 675 | Don't fall into the trap of writing for the wrong audience. Your |
| 676 | primary audience is a reasonably experienced developer with at least |
| 677 | a moderate understanding of your module's application domain, who's just |
| 678 | downloaded your module and wants to start using it as quickly as possible. |
| 679 | .PP |
| 680 | Tutorials, end-user documentation, research papers, FAQs etc are not |
| 681 | appropriate in a module's main documentation. If you really want to |
| 682 | write these, include them as sub-documents such as \f(CW\*(C`My::Module::Tutorial\*(C'\fR or |
| 683 | \&\f(CW\*(C`My::Module::FAQ\*(C'\fR and provide a link in the \s-1SEE\s0 \s-1ALSO\s0 section of the |
| 684 | main documentation. |
| 685 | .SH "SEE ALSO" |
| 686 | .IX Header "SEE ALSO" |
| 687 | .IP "perlstyle" 4 |
| 688 | .IX Item "perlstyle" |
| 689 | General Perl style guide |
| 690 | .IP "perlnewmod" 4 |
| 691 | .IX Item "perlnewmod" |
| 692 | How to create a new module |
| 693 | .IP "perlpod" 4 |
| 694 | .IX Item "perlpod" |
| 695 | \&\s-1POD\s0 documentation |
| 696 | .IP "podchecker" 4 |
| 697 | .IX Item "podchecker" |
| 698 | Verifies your \s-1POD\s0's correctness |
| 699 | .IP "Packaging Tools" 4 |
| 700 | .IX Item "Packaging Tools" |
| 701 | ExtUtils::MakeMaker, Module::Build |
| 702 | .IP "Testing tools" 4 |
| 703 | .IX Item "Testing tools" |
| 704 | Test::Simple, Test::Inline, Carp::Assert, Test::More, Test::MockObject |
| 705 | .IP "http://pause.perl.org/" 4 |
| 706 | .IX Item "http://pause.perl.org/" |
| 707 | Perl Authors Upload Server. Contains links to information for module |
| 708 | authors. |
| 709 | .IP "Any good book on software engineering" 4 |
| 710 | .IX Item "Any good book on software engineering" |
| 711 | .SH "AUTHOR" |
| 712 | .IX Header "AUTHOR" |
| 713 | Kirrily \*(L"Skud\*(R" Robert <skud@cpan.org> |