Commit | Line | Data |
---|---|---|
86530b38 AT |
1 | .\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13 |
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 "2002-06-08" "perl v5.8.0" "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 | |
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 (usually \*(L"perl Makefile.PL; make; make install\*(R"). | |
531 | .PP | |
532 | Release notes or changelogs should be produced for each release of your | |
533 | software describing user-visible changes to your module, in terms | |
534 | relevant to the user. | |
535 | .SH "RELEASE CONSIDERATIONS" | |
536 | .IX Header "RELEASE CONSIDERATIONS" | |
537 | .Sh "Version numbering" | |
538 | .IX Subsection "Version numbering" | |
539 | Version numbers should indicate at least major and minor releases, and | |
540 | possibly sub-minor releases. A major release is one in which most of | |
541 | the functionality has changed, or in which major new functionality is | |
542 | added. A minor release is one in which a small amount of functionality | |
543 | has been added or changed. Sub-minor version numbers are usually used | |
544 | for changes which do not affect functionality, such as documentation | |
545 | patches. | |
546 | .PP | |
547 | The most common \s-1CPAN\s0 version numbering scheme looks like this: | |
548 | .PP | |
549 | .Vb 1 | |
550 | \& 1.00, 1.10, 1.11, 1.20, 1.30, 1.31, 1.32 | |
551 | .Ve | |
552 | .PP | |
553 | A correct \s-1CPAN\s0 version number is a floating point number with at least | |
554 | 2 digits after the decimal. You can test whether it conforms to \s-1CPAN\s0 by | |
555 | using | |
556 | .PP | |
557 | .Vb 1 | |
558 | \& perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' 'Foo.pm' | |
559 | .Ve | |
560 | .PP | |
561 | If you want to release a 'beta' or 'alpha' version of a module but | |
562 | don't want \s-1CPAN\s0.pm to list it as most recent use an '_' after the | |
563 | regular version number followed by at least 2 digits, eg. 1.20_01. If | |
564 | you do this, the following idiom is recommended: | |
565 | .PP | |
566 | .Vb 3 | |
567 | \& $VERSION = "1.12_01"; | |
568 | \& $XS_VERSION = $VERSION; # only needed if you have XS code | |
569 | \& $VERSION = eval $VERSION; | |
570 | .Ve | |
571 | .PP | |
572 | With that trick MakeMaker will only read the first line and thus read | |
573 | the underscore, while the perl interpreter will evaluate the \f(CW$VERSION\fR | |
574 | and convert the string into a number. Later operations that treat | |
575 | \&\f(CW$VERSION\fR as a number will then be able to do so without provoking a | |
576 | warning about \f(CW$VERSION\fR not being a number. | |
577 | .PP | |
578 | Never release anything (even a one-word documentation patch) without | |
579 | incrementing the number. Even a one-word documentation patch should | |
580 | result in a change in version at the sub-minor level. | |
581 | .Sh "Pre-requisites" | |
582 | .IX Subsection "Pre-requisites" | |
583 | Module authors should carefully consider whether to rely on other | |
584 | modules, and which modules to rely on. | |
585 | .PP | |
586 | Most importantly, choose modules which are as stable as possible. In | |
587 | order of preference: | |
588 | .IP "\(bu" 4 | |
589 | Core Perl modules | |
590 | .IP "\(bu" 4 | |
591 | Stable \s-1CPAN\s0 modules | |
592 | .IP "\(bu" 4 | |
593 | Unstable \s-1CPAN\s0 modules | |
594 | .IP "\(bu" 4 | |
595 | Modules not available from \s-1CPAN\s0 | |
596 | .PP | |
597 | Specify version requirements for other Perl modules in the | |
598 | pre-requisites in your Makefile.PL. | |
599 | .PP | |
600 | Be sure to specify Perl version requirements both in Makefile.PL and | |
601 | with \f(CW\*(C`require 5.6.1\*(C'\fR or similar. | |
602 | .Sh "Testing" | |
603 | .IX Subsection "Testing" | |
604 | All modules should be tested before distribution (using \*(L"make disttest\*(R", | |
605 | and the tests should also be available to people installing the modules | |
606 | (using \*(L"make test\*(R"). | |
607 | .PP | |
608 | The importance of these tests is proportional to the alleged stability of a | |
609 | module \*(-- a module which purports to be stable or which hopes to achieve wide | |
610 | use should adhere to as strict a testing regime as possible. | |
611 | .PP | |
612 | Useful modules to help you write tests (with minimum impact on your | |
613 | development process or your time) include Test::Simple, Carp::Assert | |
614 | and Test::Inline. | |
615 | .Sh "Packaging" | |
616 | .IX Subsection "Packaging" | |
617 | Modules should be packaged using the standard MakeMaker tools, allowing | |
618 | them to be installed in a consistent manner. Use \*(L"make dist\*(R" to create | |
619 | your package. | |
620 | .PP | |
621 | Tools exist to help you build your module in a MakeMaker-friendly style. | |
622 | These include ExtUtils::ModuleMaker and h2xs. See also perlnewmod. | |
623 | .Sh "Licensing" | |
624 | .IX Subsection "Licensing" | |
625 | Make sure that your module has a license, and that the full text of it | |
626 | is included in the distribution (unless it's a common one and the terms | |
627 | of the license don't require you to include it). | |
628 | .PP | |
629 | If you don't know what license to use, dual licensing under the \s-1GPL\s0 | |
630 | and Artistic licenses (the same as Perl itself) is a good idea. | |
631 | .SH "COMMON PITFALLS" | |
632 | .IX Header "COMMON PITFALLS" | |
633 | .Sh "Reinventing the wheel" | |
634 | .IX Subsection "Reinventing the wheel" | |
635 | There are certain application spaces which are already very, very well | |
636 | served by \s-1CPAN\s0. One example is templating systems, another is date and | |
637 | time modules, and there are many more. While it is a rite of passage to | |
638 | write your own version of these things, please consider carefully | |
639 | whether the Perl world really needs you to publish it. | |
640 | .Sh "Trying to do too much" | |
641 | .IX Subsection "Trying to do too much" | |
642 | Your module will be part of a developer's toolkit. It will not, in | |
643 | itself, form the \fBentire\fR toolkit. It's tempting to add extra features | |
644 | until your code is a monolithic system rather than a set of modular | |
645 | building blocks. | |
646 | .Sh "Inappropriate documentation" | |
647 | .IX Subsection "Inappropriate documentation" | |
648 | Don't fall into the trap of writing for the wrong audience. Your | |
649 | primary audience is a reasonably experienced developer with at least | |
650 | a moderate understanding of your module's application domain, who's just | |
651 | downloaded your module and wants to start using it as quickly as possible. | |
652 | .PP | |
653 | Tutorials, end-user documentation, research papers, FAQs etc are not | |
654 | appropriate in a module's main documentation. If you really want to | |
655 | write these, include them as sub-documents such as \f(CW\*(C`My::Module::Tutorial\*(C'\fR or | |
656 | \&\f(CW\*(C`My::Module::FAQ\*(C'\fR and provide a link in the \s-1SEE\s0 \s-1ALSO\s0 section of the | |
657 | main documentation. | |
658 | .SH "SEE ALSO" | |
659 | .IX Header "SEE ALSO" | |
660 | .IP "perlstyle" 4 | |
661 | .IX Item "perlstyle" | |
662 | General Perl style guide | |
663 | .IP "perlnewmod" 4 | |
664 | .IX Item "perlnewmod" | |
665 | How to create a new module | |
666 | .IP "perlpod" 4 | |
667 | .IX Item "perlpod" | |
668 | \&\s-1POD\s0 documentation | |
669 | .IP "podchecker" 4 | |
670 | .IX Item "podchecker" | |
671 | Verifies your \s-1POD\s0's correctness | |
672 | .IP "Testing tools" 4 | |
673 | .IX Item "Testing tools" | |
674 | Test::Simple, Test::Inline, Carp::Assert | |
675 | .IP "http://pause.perl.org/" 4 | |
676 | .IX Item "http://pause.perl.org/" | |
677 | Perl Authors Upload Server. Contains links to information for module | |
678 | authors. | |
679 | .IP "Any good book on software engineering" 4 | |
680 | .IX Item "Any good book on software engineering" | |
681 | .SH "AUTHOR" | |
682 | .IX Header "AUTHOR" | |
683 | Kirrily \*(L"Skud\*(R" Robert <skud@cpan.org> |