source: trunk/essentials/dev-lang/perl/pod/perlmodstyle.pod@ 3609

Last change on this file since 3609 was 3181, checked in by bird, 19 years ago

perl 5.8.8

File size: 20.6 KB
Line 
1=head1 NAME
2
3perlmodstyle - Perl module style guide
4
5=head1 INTRODUCTION
6
7This document attempts to describe the Perl Community's "best practice"
8for writing Perl modules. It extends the recommendations found in
9L<perlstyle> , which should be considered required reading
10before reading this document.
11
12While this document is intended to be useful to all module authors, it is
13particularly aimed at authors who wish to publish their modules on CPAN.
14
15The focus is on elements of style which are visible to the users of a
16module, rather than those parts which are only seen by the module's
17developers. However, many of the guidelines presented in this document
18can be extrapolated and applied successfully to a module's internals.
19
20This document differs from L<perlnewmod> in that it is a style guide
21rather than a tutorial on creating CPAN modules. It provides a
22checklist against which modules can be compared to determine whether
23they conform to best practice, without necessarily describing in detail
24how to achieve this.
25
26All the advice contained in this document has been gleaned from
27extensive conversations with experienced CPAN authors and users. Every
28piece of advice given here is the result of previous mistakes. This
29information is here to help you avoid the same mistakes and the extra
30work that would inevitably be required to fix them.
31
32The first section of this document provides an itemized checklist;
33subsequent sections provide a more detailed discussion of the items on
34the list. The final section, "Common Pitfalls", describes some of the
35most popular mistakes made by CPAN authors.
36
37=head1 QUICK CHECKLIST
38
39For more detail on each item in this checklist, see below.
40
41=head2 Before you start
42
43=over 4
44
45=item *
46
47Don't re-invent the wheel
48
49=item *
50
51Patch, extend or subclass an existing module where possible
52
53=item *
54
55Do one thing and do it well
56
57=item *
58
59Choose an appropriate name
60
61=back
62
63=head2 The API
64
65=over 4
66
67=item *
68
69API should be understandable by the average programmer
70
71=item *
72
73Simple methods for simple tasks
74
75=item *
76
77Separate functionality from output
78
79=item *
80
81Consistent naming of subroutines or methods
82
83=item *
84
85Use named parameters (a hash or hashref) when there are more than two
86parameters
87
88=back
89
90=head2 Stability
91
92=over 4
93
94=item *
95
96Ensure your module works under C<use strict> and C<-w>
97
98=item *
99
100Stable modules should maintain backwards compatibility
101
102=back
103
104=head2 Documentation
105
106=over 4
107
108=item *
109
110Write documentation in POD
111
112=item *
113