1PERLPODSTYLE(1) User Contributed Perl Documentation PERLPODSTYLE(1)
2
6 perlpodstyle - Perl POD style guide
7
9 These are general guidelines for how to write POD documentation for
10 Perl scripts and modules, based on general guidelines for writing good
11 UNIX man pages. All of these guidelines are, of course, optional, but
12 following them will make your documentation more consistent with other
13 documentation on the system.
14 The name of the program being documented is conventionally written in
16 bold (using B<>) wherever it occurs, as are all program options.
17 Arguments should be written in italics (I<>). Function names are
18 traditionally written in italics; if you write a function as
19 function(), Pod::Man will take care of this for you. Literal code or
20 commands should be in C<>. References to other man pages should be in
21 the form manpage(section) or "L<manpage(section)>", and Pod::Man will
22 automatically format those appropriately. The second form, with L<>,
23 is used to request that a POD formatter make a link to the man page if
24 possible. As an exception, one normally omits the section when
25 referring to module documentation since it's not clear what section
26 module documentation will be in; use "L<Module::Name>" for module
27 references instead.
28 References to other programs or functions are normally in the form of
30 man page references so that cross-referencing tools can provide the
31 user with links and the like. It's possible to overdo this, though, so
32 be careful not to clutter your documentation with too much markup.
33 References to other programs that are not given as man page references
34 should be enclosed in B<>.
35 The major headers should be set out using a "=head1" directive, and are
37 historically written in the rather startling ALL UPPER CASE format;
38 this is not mandatory, but it's strongly recommended so that sections
39 have consistent naming across different software packages. Minor
40 headers may be included using "=head2", and are typically in mixed
41 case.
42 The standard sections of a manual page are:
44 NAME
46 Mandatory section; should be a comma-separated list of programs or
47 functions documented by this POD page, such as:
48 foo, bar - programs to do something
50 Manual page indexers are often extremely picky about the format of
52 this section, so don't put anything in it except this line. Every
53 program or function documented by this POD page should be listed,
54 separated by a comma and a space. For a Perl module, just give the
55 module name. A single dash, and only a single dash, should
56 separate the list of programs or functions from the description.
57 Do not use any markup such as C<> or B<> anywhere in this line.
58 Functions should not be qualified with "()" or the like. The
59 description should ideally fit on a single line, even if a man
60 program replaces the dash with a few tabs.
61 SYNOPSIS
63 A short usage summary for programs and functions. This section is
64 mandatory for section 3 pages. For Perl module documentation, it's
65 usually convenient to have the contents of this section be a
66 verbatim block showing some (brief) examples of typical ways the
67 module is used.
68 DESCRIPTION
70 Extended description and discussion of the program or functions, or
71 the body of the documentation for man pages that document something
72 else. If particularly long, it's a good idea to break this up into
73 subsections "=head2" directives like:
74 =head2 Normal Usage
76 =head2 Advanced Features
78 =head2 Writing Configuration Files
80 or whatever is appropriate for your documentation.
82 For a module, this is generally where the documentation of the
84 interfaces provided by the module goes, usually in the form of a
85 list with an "=item" for each interface. Depending on how many
86 interfaces there are, you may want to put that documentation in
87 separate METHODS, FUNCTIONS, CLASS METHODS, or INSTANCE METHODS
88 sections instead and save the DESCRIPTION section for an overview.
89 OPTIONS
91 Detailed description of each of the command-line options taken by
92 the program. This should be separate from the description for the
93 use of parsers like Pod::Usage. This is normally presented as a
94 list, with each option as a separate "=item". The specific option
95 string should be enclosed in B<>. Any values that the option takes
96 should be enclosed in I<>. For example, the section for the option
97 --section=manext would be introduced with:
98 =item B<--section>=I<manext>
100 Synonymous options (like both the short and long forms) are
102 separated by a comma and a space on the same "=item" line, or
103 optionally listed as their own item with a reference to the
104 canonical name. For example, since --section can also be written
105 as -s, the above would be:
106 =item B<-s> I<manext>, B<--section>=I<manext>
108 Writing the short option first is recommended because it's easier
110 to read. The long option is long enough to draw the eye to it
111 anyway and the short option can otherwise get lost in visual noise.
112 RETURN VALUE
114 What the program or function returns, if successful. This section
115 can be omitted for programs whose precise exit codes aren't
116 important, provided they return 0 on success and non-zero on
117 failure as is standard. It should always be present for functions.
118 For modules, it may be useful to summarize return values from the
119 module interface here, or it may be more useful to discuss return
120 values separately in the documentation of each function or method
121 the module provides.
122 ERRORS
124 Exceptions, error return codes, exit statuses, and errno settings.
125 Typically used for function or module documentation; program
126 documentation uses DIAGNOSTICS instead. The general rule of thumb
127 is that errors printed to "STDOUT" or "STDERR" and intended for the
128 end user are documented in DIAGNOSTICS while errors passed internal
129 to the calling program and intended for other programmers are
130 documented in ERRORS. When documenting a function that sets errno,
131 a full list of the possible errno values should be given here.
132 DIAGNOSTICS
134 All possible messages the program can print out and what they mean.
135 You may wish to follow the same documentation style as the Perl
136 documentation; see perldiag(1) for more details (and look at the
137 POD source as well).
138 If applicable, please include details on what the user should do to
140 correct the error; documenting an error as indicating "the input
141 buffer is too small" without telling the user how to increase the
142 size of the input buffer (or at least telling them that it isn't
143 possible) aren't very useful.
144 EXAMPLES
146 Give some example uses of the program or function. Don't skimp;
147 users often find this the most useful part of the documentation.
148 The examples are generally given as verbatim paragraphs.
149 Don't just present an example without explaining what it does.
151 Adding a short paragraph saying what the example will do can
152 increase the value of the example immensely.
153 ENVIRONMENT
155 Environment variables that the program cares about, normally
156 presented as a list using "=over", "=item", and "=back". For
157 example:
158 =over 6
160 =item HOME
162 Used to determine the user's home directory. F<.foorc> in this
164 directory is read for configuration details, if it exists.
165 =back
167 Since environment variables are normally in all uppercase, no
169 additional special formatting is generally needed; they're glaring
170 enough as it is.
171 FILES
173 All files used by the program or function, normally presented as a
174 list, and what it uses them for. File names should be enclosed in
175 F<>. It's particularly important to document files that will be
176 potentially modified.
177 CAVEATS
179 Things to take special care with, sometimes called WARNINGS.
180 BUGS
182 Things that are broken or just don't work quite right.
183 RESTRICTIONS
185 Bugs you don't plan to fix. :-)
186 NOTES
188 Miscellaneous commentary.
189 AUTHOR
191 Who wrote it (use AUTHORS for multiple people). It's a good idea
192 to include your current e-mail address (or some e-mail address to
193 which bug reports should be sent) or some other contact information
194 so that users have a way of contacting you. Remember that program
195 documentation tends to roam the wild for far longer than you expect
196 and pick a contact method that's likely to last.
197 HISTORY
199 Programs derived from other sources sometimes have this. Some
200 people keep a modification log here, but that usually gets long and
201 is normally better maintained in a separate file.
202 COPYRIGHT AND LICENSE
204 For copyright
205 Copyright YEAR(s) YOUR NAME(s)
207 (No, (C) is not needed. No, "all rights reserved" is not needed.)
209 For licensing the easiest way is to use the same licensing as Perl
211 itself:
212 This library is free software; you may redistribute it and/or
214 modify it under the same terms as Perl itself.
215 This makes it easy for people to use your module with Perl. Note
217 that this licensing example is neither an endorsement or a
218 requirement, you are of course free to choose any licensing.
219 SEE ALSO
221 Other man pages to check out, like man(1), man(7), makewhatis(8),
222 or catman(8). Normally a simple list of man pages separated by
223 commas, or a paragraph giving the name of a reference work. Man
224 page references, if they use the standard name(section) form, don't
225 have to be enclosed in L<> (although it's recommended), but other
226 things in this section probably should be when appropriate.
227 If the package has a mailing list, include a URL or subscription
229 instructions here.
230 If the package has a web site, include a URL here.
232 Documentation of object-oriented libraries or modules may want to use
234 CONSTRUCTORS and METHODS sections, or CLASS METHODS and INSTANCE
235 METHODS sections, for detailed documentation of the parts of the
236 library and save the DESCRIPTION section for an overview. Large
237 modules with a function interface may want to use FUNCTIONS for similar
238 reasons. Some people use OVERVIEW to summarize the description if it's
239 quite long.
240 Section ordering varies, although NAME must always be the first section
242 (you'll break some man page systems otherwise), and NAME, SYNOPSIS,
243 DESCRIPTION, and OPTIONS generally always occur first and in that order
244 if present. In general, SEE ALSO, AUTHOR, and similar material should
245 be left for last. Some systems also move WARNINGS and NOTES to last.
246 The order given above should be reasonable for most purposes.
247 Some systems use CONFORMING TO to note conformance to relevant
249 standards and MT-LEVEL to note safeness for use in threaded programs or
250 signal handlers. These headings are primarily useful when documenting
251 parts of a C library.
252 Finally, as a general note, try not to use an excessive amount of
254 markup. As documented here and in Pod::Man, you can safely leave Perl
255 variables, function names, man page references, and the like unadorned
256 by markup and the POD translators will figure it out for you. This
257 makes it much easier to later edit the documentation. Note that many
258 existing translators will do the wrong thing with e-mail addresses when
259 wrapped in L<>, so don't do that.
260
262 Russ Allbery <rra@cpan.org>, with large portions of this documentation
263 taken from the documentation of the original pod2man implementation by
264 Larry Wall and Tom Christiansen.
265
267 Copyright 1999, 2000, 2001, 2004, 2006, 2008, 2010, 2015, 2018 Russ
268 Allbery <rra@cpan.org>
269 Copying and distribution of this file, with or without modification,
271 are permitted in any medium without royalty provided the copyright
272 notice and this notice are preserved. This file is offered as-is,
273 without any warranty.
274 SPDX-License-Identifier: FSFAP
276
278 For additional information that may be more accurate for your specific
279 system, see either man(5) or man(7) depending on your system manual
280 section numbering conventions.
281 This documentation is maintained as part of the podlators distribution.
283 The current version is always available from its web site at
284 <https://www.eyrie.org/~eagle/software/podlators/>.
285perl v5.38.0 2023-07-21 PERLPODSTYLE(1)