1PERLPODSTYLE(1)       User Contributed Perl Documentation      PERLPODSTYLE(1)
2
3
4

NAME

6       perlpodstyle - Perl POD style guide
7

DESCRIPTION

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
15       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
29       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
36       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
43       The standard sections of a manual page are:
44
45       NAME
46           Mandatory section; should be a comma-separated list of programs or
47           functions documented by this POD page, such as:
48
49               foo, bar - programs to do something
50
51           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
62       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
69       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
75               =head2 Normal Usage
76
77               =head2 Advanced Features
78
79               =head2 Writing Configuration Files
80
81           or whatever is appropriate for your documentation.
82
83           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
90       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
99               =item B<--section>=I<manext>
100
101           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
107               =item B<-s> I<manext>, B<--section>=I<manext>
108
109           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
113       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
123       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
133       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
139           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
145       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
150           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
154       ENVIRONMENT
155           Environment variables that the program cares about, normally
156           presented as a list using "=over", "=item", and "=back".  For
157           example:
158
159               =over 6
160
161               =item HOME
162
163               Used to determine the user's home directory.  F<.foorc> in this
164               directory is read for configuration details, if it exists.
165
166               =back
167
168           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
172       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
178       CAVEATS
179           Things to take special care with, sometimes called WARNINGS.
180
181       BUGS
182           Things that are broken or just don't work quite right.
183
184       RESTRICTIONS
185           Bugs you don't plan to fix.  :-)
186
187       NOTES
188           Miscellaneous commentary.
189
190       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
198       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
203       COPYRIGHT AND LICENSE
204           For copyright
205
206               Copyright YEAR(s) YOUR NAME(s)
207
208           (No, (C) is not needed.  No, "all rights reserved" is not needed.)
209
210           For licensing the easiest way is to use the same licensing as Perl
211           itself:
212
213               This library is free software; you may redistribute it and/or
214               modify it under the same terms as Perl itself.
215
216           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
220       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,
225           don't have to be enclosed in L<> (although it's recommended), but
226           other things in this section probably should be when appropriate.
227
228           If the package has a mailing list, include a URL or subscription
229           instructions here.
230
231           If the package has a web site, include a URL here.
232
233       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
241       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
248       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
253       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

AUTHOR

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
270       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
275       SPDX-License-Identifier: FSFAP
276

SEE ALSO

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
282       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/>.
285
286
287
288perl v5.28.1                      2018-05-07                   PERLPODSTYLE(1)
Impressum