FM / pod

/usr/share/perl5/pod

Name	Size	Mode	Actions
perl.pod	16270	0644	edit dl rm
perl56delta.pod	107201	0644	edit dl rm
perl58delta.pod	115165	0644	edit dl rm
perl561delta.pod	124713	0644	edit dl rm
perl581delta.pod	38061	0644	edit dl rm
perl582delta.pod	4470	0644	edit dl rm
perl583delta.pod	6335	0644	edit dl rm
perl584delta.pod	7363	0644	edit dl rm
perl585delta.pod	5889	0644	edit dl rm
perl586delta.pod	4651	0644	edit dl rm
perl587delta.pod	8357	0644	edit dl rm
perl588delta.pod	25272	0644	edit dl rm
perl589delta.pod	53900	0644	edit dl rm
perl5004delta.pod	56240	0644	edit dl rm
perl5005delta.pod	34283	0644	edit dl rm
perl5100delta.pod	55535	0644	edit dl rm
perl5101delta.pod	43888	0644	edit dl rm
perl5120delta.pod	89272	0644	edit dl rm
perl5121delta.pod	10141	0644	edit dl rm
perl5122delta.pod	9603	0644	edit dl rm
perl5123delta.pod	4100	0644	edit dl rm
perl5124delta.pod	3672	0644	edit dl rm
perl5125delta.pod	7683	0644	edit dl rm
perl5140delta.pod	144324	0644	edit dl rm
perl5141delta.pod	7966	0644	edit dl rm
perl5142delta.pod	6892	0644	edit dl rm
perl5143delta.pod	7760	0644	edit dl rm
perl5144delta.pod	6327	0644	edit dl rm
perl5160delta.pod	133651	0644	edit dl rm
perl5161delta.pod	6142	0644	edit dl rm
perl5162delta.pod	3594	0644	edit dl rm
perl5163delta.pod	4085	0644	edit dl rm
perl5180delta.pod	119431	0644	edit dl rm
perl5181delta.pod	6595	0644	edit dl rm
perl5182delta.pod	5335	0644	edit dl rm
perl5184delta.pod	4642	0644	edit dl rm
perl5200delta.pod	115699	0644	edit dl rm
perl5201delta.pod	10899	0644	edit dl rm
perl5202delta.pod	12509	0644	edit dl rm
perl5203delta.pod	9392	0644	edit dl rm
perl5220delta.pod	130963	0644	edit dl rm
perl5221delta.pod	10767	0644	edit dl rm
perl5222delta.pod	12629	0644	edit dl rm
perl5223delta.pod	8456	0644	edit dl rm
perl5224delta.pod	4460	0644	edit dl rm
perl5240delta.pod	64927	0644	edit dl rm
perl5241delta.pod	8215	0644	edit dl rm
perl5242delta.pod	4113	0644	edit dl rm
perl5243delta.pod	11428	0644	edit dl rm
perl5244delta.pod	4510	0644	edit dl rm
perl5260delta.pod	101836	0644	edit dl rm
perl5261delta.pod	7927	0644	edit dl rm
perl5262delta.pod	7880	0644	edit dl rm
perl5263delta.pod	7063	0644	edit dl rm
perl5280delta.pod	72113	0644	edit dl rm
perlaix.pod	20437	0644	edit dl rm
perlamiga.pod	5749	0644	edit dl rm
perlandroid.pod	7871	0644	edit dl rm
perlapi.pod	443535	0644	edit dl rm
perlapio.pod	19285	0644	edit dl rm
perlartistic.pod	7010	0644	edit dl rm
perlbook.pod	8338	0644	edit dl rm
perlboot.pod	294	0644	edit dl rm
perlbot.pod	304	0644	edit dl rm
perlbs2000.pod	8058	0644	edit dl rm
perlcall.pod	56706	0644	edit dl rm
perlce.pod	14602	0644	edit dl rm
perlcheat.pod	4481	0644	edit dl rm
perlclib.pod	9619	0644	edit dl rm
perlcn.pod	4691	0644	edit dl rm
perlcommunity.pod	7217	0644	edit dl rm
perlcygwin.pod	27199	0644	edit dl rm
perldata.pod	46743	0644	edit dl rm
perldbmfilter.pod	4981	0644	edit dl rm
perldebguts.pod	38535	0644	edit dl rm
perldebtut.pod	22152	0644	edit dl rm
perldebug.pod	39258	0644	edit dl rm
perldelta.pod	7063	0644	edit dl rm
perldeprecation.pod	18169	0644	edit dl rm
perldiag.pod	284572	0644	edit dl rm
perldos.pod	10522	0644	edit dl rm
perldsc.pod	25614	0644	edit dl rm
perldtrace.pod	7958	0644	edit dl rm
perlebcdic.pod	84233	0644	edit dl rm
perlembed.pod	37196	0644	edit dl rm
perlexperiment.pod	7195	0644	edit dl rm
perlfork.pod	13355	0644	edit dl rm
perlform.pod	16608	0644	edit dl rm
perlfreebsd.pod	1610	0644	edit dl rm
perlfunc.pod	392957	0644	edit dl rm
perlgit.pod	33509	0644	edit dl rm
perlgpl.pod	13815	0644	edit dl rm
perlguts.pod	139329	0644	edit dl rm
perlhack.pod	40445	0644	edit dl rm
perlhacktips.pod	55509	0644	edit dl rm
perlhacktut.pod	6153	0644	edit dl rm
perlhaiku.pod	1508	0644	edit dl rm
perlhist.pod	53546	0644	edit dl rm
perlhpux.pod	30509	0644	edit dl rm
perlhurd.pod	1993	0644	edit dl rm
perlintern.pod	54572	0644	edit dl rm
perlinterp.pod	33687	0644	edit dl rm
perlintro.pod	22119	0644	edit dl rm
perliol.pod	34185	0644	edit dl rm
perlipc.pod	70829	0644	edit dl rm
perlirix.pod	4395	0644	edit dl rm
perljp.pod	7521	0644	edit dl rm
perlko.pod	12259	0644	edit dl rm
perllexwarn.pod	355	0644	edit dl rm
perllinux.pod	1488	0644	edit dl rm
perllocale.pod	68678	0644	edit dl rm
perllol.pod	9580	0644	edit dl rm
perlmacos.pod	1001	0644	edit dl rm
perlmacosx.pod	12060	0644	edit dl rm
perlmod.pod	26250	0644	edit dl rm
perlmodinstall.pod	12792	0644	edit dl rm
perlmodlib.pod	76482	0644	edit dl rm
perlmodstyle.pod	22575	0644	edit dl rm
perlmroapi.pod	3212	0644	edit dl rm
perlnetware.pod	6648	0644	edit dl rm
perlnewmod.pod	11036	0644	edit dl rm
perlnumber.pod	8353	0644	edit dl rm
perlobj.pod	35537	0644	edit dl rm
perlootut.pod	26783	0644	edit dl rm
perlop.pod	136252	0644	edit dl rm
perlopenbsd.pod	1204	0644	edit dl rm
perlopentut.pod	9455	0644	edit dl rm
perlos2.pod	93351	0644	edit dl rm
perlos390.pod	15674	0644	edit dl rm
perlos400.pod	4768	0644	edit dl rm
perlpacktut.pod	51282	0644	edit dl rm
perlperf.pod	49881	0644	edit dl rm
perlplan9.pod	5125	0644	edit dl rm
perlpod.pod	22196	0644	edit dl rm
perlpodspec.pod	68476	0644	edit dl rm
perlpolicy.pod	25629	0644	edit dl rm
perlport.pod	87602	0644	edit dl rm
perlpragma.pod	5176	0644	edit dl rm
perlqnx.pod	6673	0644	edit dl rm
perlre.pod	120901	0644	edit dl rm
perlreapi.pod	30334	0644	edit dl rm
perlrebackslash.pod	31817	0644	edit dl rm
perlrecharclass.pod	49029	0644	edit dl rm
perlref.pod	35304	0644	edit dl rm
perlreftut.pod	18790	0644	edit dl rm
perlreguts.pod	38328	0644	edit dl rm
perlrepository.pod	509	0644	edit dl rm
perlrequick.pod	18497	0644	edit dl rm
perlreref.pod	14744	0644	edit dl rm
perlretut.pod	121257	0644	edit dl rm
perlriscos.pod	1529	0644	edit dl rm
perlrun.pod	53550	0644	edit dl rm
perlsec.pod	26184	0644	edit dl rm
perlsolaris.pod	29822	0644	edit dl rm
perlsource.pod	6876	0644	edit dl rm
perlstyle.pod	8630	0644	edit dl rm
perlsub.pod	72967	0644	edit dl rm
perlsymbian.pod	15359	0644	edit dl rm
perlsyn.pod	44512	0644	edit dl rm
perlsynology.pod	7778	0644	edit dl rm
perlthrtut.pod	46459	0644	edit dl rm
perltie.pod	38607	0644	edit dl rm
perltoc.pod	694171	0644	edit dl rm
perltodo.pod	376	0644	edit dl rm
perltooc.pod	294	0644	edit dl rm
perltoot.pod	294	0644	edit dl rm
perltrap.pod	10620	0644	edit dl rm
perltru64.pod	8492	0644	edit dl rm
perltw.pod	4477	0644	edit dl rm
perlunicode.pod	82491	0644	edit dl rm
perlunicook.pod	25488	0644	edit dl rm
perlunifaq.pod	13647	0644	edit dl rm
perluniintro.pod	38340	0644	edit dl rm
perluniprops.pod	285306	0644	edit dl rm
perlunitut.pod	7951	0644	edit dl rm
perlutil.pod	7640	0644	edit dl rm
perlvar.pod	78364	0644	edit dl rm
perlvms.pod	50823	0644	edit dl rm
perlvos.pod	3843	0644	edit dl rm
perlwin32.pod	39298	0644	edit dl rm
perlxs.pod	78920	0644	edit dl rm
perlxstut.pod	50095	0644	edit dl rm
perlxstypemap.pod	24001	0644	edit dl rm

Edit: /usr/share/perl5/pod/perlstyle.pod (8630B)

=head1 NAME

perlstyle - Perl style guide

=head1 DESCRIPTION

Each programmer will, of course, have his or her own preferences in
regards to formatting, but there are some general guidelines that will
make your programs easier to read, understand, and maintain.

The most important thing is to run your programs under the B<-w>
flag at all times.  You may turn it off explicitly for particular
portions of code via the C<no warnings> pragma or the C<$^W> variable
if you must.  You should also always run under C<use strict> or know the
reason why not.  The C<use sigtrap> and even C<use diagnostics> pragmas
may also prove useful.

Regarding aesthetics of code lay out, about the only thing Larry
cares strongly about is that the closing curly bracket of
a multi-line BLOCK should line up with the keyword that started the construct.
Beyond that, he has other preferences that aren't so strong:

=over 4

=item *

4-column indent.

=item *

Opening curly on same line as keyword, if possible, otherwise line up.

=item *

Space before the opening curly of a multi-line BLOCK.

=item *

One-line BLOCK may be put on one line, including curlies.

=item *

No space before the semicolon.

=item *

Semicolon omitted in "short" one-line BLOCK.

=item *

Space around most operators.

=item *

Space around a "complex" subscript (inside brackets).

=item *

Blank lines between chunks that do different things.

=item *

Uncuddled elses.

=item *

No space between function name and its opening parenthesis.

=item *

Space after each comma.

=item *

Long lines broken after an operator (except C<and> and C<or>).

=item *

Space after last parenthesis matching on current line.

=item *

Line up corresponding items vertically.

=item *

Omit redundant punctuation as long as clarity doesn't suffer.

=back

Larry has his reasons for each of these things, but he doesn't claim that
everyone else's mind works the same as his does.

Here are some other more substantive style issues to think about:

=over 4

=item *

Just because you I<CAN> do something a particular way doesn't mean that
you I<SHOULD> do it that way.  Perl is designed to give you several
ways to do anything, so consider picking the most readable one.  For
instance

open(FOO,$foo) || die "Can't open $foo: $!";

is better than

die "Can't open $foo: $!" unless open(FOO,$foo);

because the second way hides the main point of the statement in a
modifier.  On the other hand

print "Starting analysis\n" if $verbose;

is better than

$verbose && print "Starting analysis\n";

because the main point isn't whether the user typed B<-v> or not.

Similarly, just because an operator lets you assume default arguments
doesn't mean that you have to make use of the defaults.  The defaults
are there for lazy systems programmers writing one-shot programs.  If
you want your program to be readable, consider supplying the argument.

Along the same lines, just because you I<CAN> omit parentheses in many
places doesn't mean that you ought to:

return print reverse sort num values %array;
    return print(reverse(sort num (values(%array))));

When in doubt, parenthesize.  At the very least it will let some poor
schmuck bounce on the % key in B<vi>.

Even if you aren't in doubt, consider the mental welfare of the person
who has to maintain the code after you, and who will probably put
parentheses in the wrong place.

=item *

Don't go through silly contortions to exit a loop at the top or the
bottom, when Perl provides the C<last> operator so you can exit in
the middle.  Just "outdent" it a little to make it more visible:

LINE:
	for (;;) {
	    statements;
	  last LINE if $foo;
	    next LINE if /^#/;
	    statements;
	}

=item *

Don't be afraid to use loop labels--they're there to enhance
readability as well as to allow multilevel loop breaks.  See the
previous example.

=item *

Avoid using C<grep()> (or C<map()>) or `backticks` in a void context, that is,
when you just throw away their return values.  Those functions all
have return values, so use them.  Otherwise use a C<foreach()> loop or
the C<system()> function instead.

=item *

For portability, when using features that may not be implemented on
every machine, test the construct in an eval to see if it fails.  If
you know what version or patchlevel a particular feature was
implemented, you can test C<$]> (C<$PERL_VERSION> in C<English>) to see if it
will be there.  The C<Config> module will also let you interrogate values
determined by the B<Configure> program when Perl was installed.

=item *

Choose mnemonic identifiers.  If you can't remember what mnemonic means,
you've got a problem.

=item *

While short identifiers like C<$gotit> are probably ok, use underscores to
separate words in longer identifiers.  It is generally easier to read
C<$var_names_like_this> than C<$VarNamesLikeThis>, especially for
non-native speakers of English. It's also a simple rule that works
consistently with C<VAR_NAMES_LIKE_THIS>.

Package names are sometimes an exception to this rule.  Perl informally
reserves lowercase module names for "pragma" modules like C<integer> and
C<strict>.  Other modules should begin with a capital letter and use mixed
case, but probably without underscores due to limitations in primitive
file systems' representations of module names as files that must fit into a
few sparse bytes.

=item *

You may find it helpful to use letter case to indicate the scope
or nature of a variable. For example:

$ALL_CAPS_HERE   constants only (beware clashes with perl vars!)
    $Some_Caps_Here  package-wide global/static
    $no_caps_here    function scope my() or local() variables

Function and method names seem to work best as all lowercase.
E.g., C<$obj-E<gt>as_string()>.

You can use a leading underscore to indicate that a variable or
function should not be used outside the package that defined it.

=item *

If you have a really hairy regular expression, use the C</x>  or C</xx>
modifiers and put in some whitespace to make it look a little less like
line noise.
Don't use slash as a delimiter when your regexp has slashes or backslashes.

=item *

Use the new C<and> and C<or> operators to avoid having to parenthesize
list operators so much, and to reduce the incidence of punctuation
operators like C<&&> and C<||>.  Call your subroutines as if they were
functions or list operators to avoid excessive ampersands and parentheses.

=item *

Use here documents instead of repeated C<print()> statements.

=item *

Line up corresponding things vertically, especially if it'd be too long
to fit on one line anyway.

$IDX = $ST_MTIME;
    $IDX = $ST_ATIME 	   if $opt_u;
    $IDX = $ST_CTIME 	   if $opt_c;
    $IDX = $ST_SIZE  	   if $opt_s;

mkdir $tmpdir, 0700	or die "can't mkdir $tmpdir: $!";
    chdir($tmpdir)      or die "can't chdir $tmpdir: $!";
    mkdir 'tmp',   0777	or die "can't mkdir $tmpdir/tmp: $!";

=item *

Always check the return codes of system calls.  Good error messages should
go to C<STDERR>, include which program caused the problem, what the failed
system call and arguments were, and (VERY IMPORTANT) should contain the
standard system error message for what went wrong.  Here's a simple but
sufficient example:

opendir(D, $dir)	 or die "can't opendir $dir: $!";

=item *

Line up your transliterations when it makes sense:

tr [abc]
       [xyz];

=item *

Think about reusability.  Why waste brainpower on a one-shot when you
might want to do something like it again?  Consider generalizing your
code.  Consider writing a module or object class.  Consider making your
code run cleanly with C<use strict> and C<use warnings> (or B<-w>) in
effect.  Consider giving away your code.  Consider changing your whole
world view.  Consider... oh, never mind.

=item *

Try to document your code and use Pod formatting in a consistent way. Here
are commonly expected conventions:

=over 4

=item *

use C<CE<lt>E<gt>> for function, variable and module names (and more
generally anything that can be considered part of code, like filehandles
or specific values). Note that function names are considered more readable
with parentheses after their name, that is C<function()>.

=item *

use C<BE<lt>E<gt>> for commands names like B<cat> or B<grep>.

=item *

use C<FE<lt>E<gt>> or C<CE<lt>E<gt>> for file names. C<FE<lt>E<gt>> should
be the only Pod code for file names, but as most Pod formatters render it
as italic, Unix and Windows paths with their slashes and backslashes may
be less readable, and better rendered with C<CE<lt>E<gt>>.

=back

=item *

Be consistent.

=item *

Be nice.

=back

=head1 NAME perlstyle - Perl style guide =head1 DESCRIPTION Each programmer will, of course, have his or her own preferences in regards to formatting, but there are some general guidelines that will make your programs easier to read, understand, and maintain. The most important thing is to run your programs under the B<-w> flag at all times. You may turn it off explicitly for particular portions of code via the C pragma or the C<$^W> variable if you must. You should also always run under C or know the reason why not. The C and even C pragmas may also prove useful. Regarding aesthetics of code lay out, about the only thing Larry cares strongly about is that the closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct. Beyond that, he has other preferences that aren't so strong: =over 4 =item * 4-column indent. =item * Opening curly on same line as keyword, if possible, otherwise line up. =item * Space before the opening curly of a multi-line BLOCK. =item * One-line BLOCK may be put on one line, including curlies. =item * No space before the semicolon. =item * Semicolon omitted in "short" one-line BLOCK. =item * Space around most operators. =item * Space around a "complex" subscript (inside brackets). =item * Blank lines between chunks that do different things. =item * Uncuddled elses. =item * No space between function name and its opening parenthesis. =item * Space after each comma. =item * Long lines broken after an operator (except C and C). =item * Space after last parenthesis matching on current line. =item * Line up corresponding items vertically. =item * Omit redundant punctuation as long as clarity doesn't suffer. =back Larry has his reasons for each of these things, but he doesn't claim that everyone else's mind works the same as his does. Here are some other more substantive style issues to think about: =over 4 =item * Just because you I do something a particular way doesn't mean that you I do it that way. Perl is designed to give you several ways to do anything, so consider picking the most readable one. For instance open(FOO,$foo) || die "Can't open $foo: $!"; is better than die "Can't open $foo: $!" unless open(FOO,$foo); because the second way hides the main point of the statement in a modifier. On the other hand print "Starting analysis\n" if $verbose; is better than $verbose && print "Starting analysis\n"; because the main point isn't whether the user typed B<-v> or not. Similarly, just because an operator lets you assume default arguments doesn't mean that you have to make use of the defaults. The defaults are there for lazy systems programmers writing one-shot programs. If you want your program to be readable, consider supplying the argument. Along the same lines, just because you I omit parentheses in many places doesn't mean that you ought to: return print reverse sort num values %array; return print(reverse(sort num (values(%array)))); When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in B. Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parentheses in the wrong place. =item * Don't go through silly contortions to exit a loop at the top or the bottom, when Perl provides the C operator so you can exit in the middle. Just "outdent" it a little to make it more visible: LINE: for (;;) { statements; last LINE if $foo; next LINE if /^#/; statements; } =item * Don't be afraid to use loop labels--they're there to enhance readability as well as to allow multilevel loop breaks. See the previous example. =item * Avoid using C (or C) or `backticks` in a void context, that is, when you just throw away their return values. Those functions all have return values, so use them. Otherwise use a C loop or the C function instead. =item * For portability, when using features that may not be implemented on every machine, test the construct in an eval to see if it fails. If you know what version or patchlevel a particular feature was implemented, you can test C<$]> (C<$PERL_VERSION> in C) to see if it will be there. The C module will also let you interrogate values determined by the B program when Perl was installed. =item * Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. =item * While short identifiers like C<$gotit> are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read C<$var_names_like_this> than C<$VarNamesLikeThis>, especially for non-native speakers of English. It's also a simple rule that works consistently with C. Package names are sometimes an exception to this rule. Perl informally reserves lowercase module names for "pragma" modules like C and C. Other modules should begin with a capital letter and use mixed case, but probably without underscores due to limitations in primitive file systems' representations of module names as files that must fit into a few sparse bytes. =item * You may find it helpful to use letter case to indicate the scope or nature of a variable. For example: $ALL_CAPS_HERE constants only (beware clashes with perl vars!) $Some_Caps_Here package-wide global/static $no_caps_here function scope my() or local() variables Function and method names seem to work best as all lowercase. E.g., C<$obj-Eas_string()>. You can use a leading underscore to indicate that a variable or function should not be used outside the package that defined it. =item * If you have a really hairy regular expression, use the C or C modifiers and put in some whitespace to make it look a little less like line noise. Don't use slash as a delimiter when your regexp has slashes or backslashes. =item * Use the new C and C operators to avoid having to parenthesize list operators so much, and to reduce the incidence of punctuation operators like C<&&> and C<||>. Call your subroutines as if they were functions or list operators to avoid excessive ampersands and parentheses. =item * Use here documents instead of repeated C statements. =item * Line up corresponding things vertically, especially if it'd be too long to fit on one line anyway. $IDX = $ST_MTIME; $IDX = $ST_ATIME if $opt_u; $IDX = $ST_CTIME if $opt_c; $IDX = $ST_SIZE if $opt_s; mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!"; chdir($tmpdir) or die "can't chdir $tmpdir: $!"; mkdir 'tmp', 0777 or die "can't mkdir $tmpdir/tmp: $!"; =item * Always check the return codes of system calls. Good error messages should go to C, include which program caused the problem, what the failed system call and arguments were, and (VERY IMPORTANT) should contain the standard system error message for what went wrong. Here's a simple but sufficient example: opendir(D, $dir) or die "can't opendir $dir: $!"; =item * Line up your transliterations when it makes sense: tr [abc] [xyz]; =item * Think about reusability. Why waste brainpower on a one-shot when you might want to do something like it again? Consider generalizing your code. Consider writing a module or object class. Consider making your code run cleanly with C and C (or B<-w>) in effect. Consider giving away your code. Consider changing your whole world view. Consider... oh, never mind. =item * Try to document your code and use Pod formatting in a consistent way. Here are commonly expected conventions: =over 4 =item * use CE> for function, variable and module names (and more generally anything that can be considered part of code, like filehandles or specific values). Note that function names are considered more readable with parentheses after their name, that is C. =item * use CE> for commands names like B or B. =item * use CE> or CE> for file names. CE> should be the only Pod code for file names, but as most Pod formatters render it as italic, Unix and Windows paths with their slashes and backslashes may be less readable, and better rendered with CE>. =back =item * Be consistent. =item * Be nice. =back