7.2. Boilerplates Create standard POD templates for modules and applications.
One of the main reasons documentation can often seem so unpleasant is the "blank page effect". Many programmers simply don't know how to start, or what to say. One of the best ways to make writing documentation less forbidding (and hence more likely to actually occur) is to circumvent that initial empty screen by providing a template that developers can cut and paste into their code. For a module, that documentation template might look something like Example 7-1. For an application, the variation shown in Example 7-2 is more appropriate. Of course, the specific details that your templates provide may vary from those shown here, according to your other coding practices. The most likely variation will be in the licence and copyright, but you may also have specific in-house conventions regarding version numbering (see Chapter 17), or the grammar of diagnostic messages (see Chapter 13), or the attribution of authorship. Example 7-1. User documentation template for modules =head1 NAME <Module::Name> - <One-line description of module's purpose> =head1 VERSION The initial template usually just has: This documentation refers to <Module::Name> version 0.0.1. =head1 SYNOPSIS use <Module::Name> ; # Brief but working code example(s) here showing the most common usage(s) # This section will be as far as many users bother reading, # so make it as educational and exemplary as possible. =head1 DESCRIPTION A full description of the module and its features. May include numerous subsections (i.e., =head2, =head3, etc.). =head1 SUBROUTINES/METHODS A separate section listing the public components of the module's interface. These normally consist of either subroutines that may be exported, or methods that may be called on objects belonging to the classes that the module provides. Name the section accordingly. In an object-oriented module, this section should begin with a sentence of the form "An object of this class represents...", to give the reader a high-level context to help them understand the methods that are subsequently described. =head1 DIAGNOSTICS A list of every error and warning message that the module can generate (even the ones that will "never happen"), with a full explanation of each problem, one or more likely causes, and any suggested remedies. (See also "Documenting Errors" in Chapter 13.) =head1 CONFIGURATION AND ENVIRONMENT A full explanation of any configuration system(s) used by the module, including the names and locations of any configuration files, and the meaning of any environment variables or properties that can be set. These descriptions must also include details of any configuration language used. (See also "Configuration Files" in Chapter 19.) =head1 DEPENDENCIES A list of all the other modules that this module relies upon, including any restrictions on versions, and an indication of whether these required modules are part of the standard Perl distribution, part of the module's distribution, or must be installed separately. =head1 INCOMPATIBILITIES A list of any modules that this module cannot be used in conjunction with. This may be due to name conflicts in the interface, or competition for system or program resources, or due to internal limitations of Perl (for example, many modules that use source code filters are mutually incompatible). =head1 BUGS AND LIMITATIONS A list of known problems with the module, together with some indication of whether they are likely to be fixed in an upcoming release. Also a list of restrictions on the features the module does provide: data types that cannot be handled, performance issues and the circumstances in which they may arise, practical limitations on the size of data sets, special cases that are not (yet) handled, etc. The initial template usually just has: There are no known bugs in this module. Please report problems to <Maintainer name(s)> (<contact address> ) Patches are welcome. =head1 AUTHOR <Author name(s)> (<contact address> ) =head1 LICENCE AND COPYRIGHT Copyright (c) <year> <copyright holder> (<contact address> ). All rights reserved. followed by whatever licence you wish to release it under. For Perl code that is often just: This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See L<perlartistic>. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Example 7-2. User documenta\tion template for applications =head1 NAME <application name> - <One-line description of application's purpose> =head1 VERSION The initial template usually just has: This documentation refers to <application name> version 0.0.1. =head1 USAGE # Brief working invocation example(s) here showing the most common usage(s) # This section will be as far as many users ever read, # so make it as educational and exemplary as possible. =head1 REQUIRED ARGUMENTS A complete list of every argument that must appear on the command line. when the application is invoked, explaining what each of them does, any restrictions on where each one may appear (i.e., flags that must appear before or after filenames), and how the various arguments and options may interact (e.g., mutual exclusions, required combinations, etc.) If all of the application's arguments are optional, this section may be omitted entirely. =head1 OPTIONS A complete list of every available option with which the application can be invoked, explaining what each does, and listing any restrictions, or interactions. If the application has no options, this section may be omitted entirely. =head1 DESCRIPTION A full description of the application and its features. May include numerous subsections (i.e., =head2, =head3, etc.). =head1 DIAGNOSTICS A list of every error and warning message that the application can generate (even the ones that will "never happen"), with a full explanation of each problem, one or more likely causes, and any suggested remedies. If the application generates exit status codes (e.g., under Unix), then list the exit status associated with each error. =head1 CONFIGURATION AND ENVIRONMENT A full explanation of any configuration system(s) used by the application, including the names and locations of any configuration files, and the meaning of any environment variables or properties that can be set. These descriptions must also include details of any configuration language used. (See also "Configuration Files" in Chapter 19.) =head1 DEPENDENCIES =head1 INCOMPATIBILITIES =head1 BUGS AND LIMITATIONS =head1 AUTHOR =head1 LICENCE AND COPYRIGHT These sections are the same as in Example 7-1.
You could make it easy to load these files from templates by configuring your text editor appropriately. In your vim configuration file: iab papp ^]:r ~/.code_templates/perl_application.pl^M
Or in your Emacs configuration: ;; Load an application template in a new unattached buffer... (defun application-template-pl ( ) "Inserts the standard Perl application template" ; For help and info. (interactive "*") ; Make this user accessible. (switch-to-buffer "application-template-pl") (insert-file "~/.code_templates/perl_application.pl")) ;; Set to a specific key combination... (global-set-key "\C-ca" 'application-template-pl)
|
