To find out I<all> modules installed on your system, including
those without documentation or outside the standard release,
-jus tdo this:
+just do this:
% find `perl -e 'print "@INC"'` -name '*.pm' -print
-They should all have their own documentation installed and accessible
-via your system man(1) command. If you do not have a B<find>
+To get a log of all module distributions which have been installed
+since perl was installed, just do:
+
+ % perldoc perllocal
+
+Modules should all have their own documentation installed and accessible
+via your system man(1) command, or via the C<perldoc> program. If you do
+not have a B<find>
program, you can use the Perl B<find2perl> program instead, which
generates Perl code as output you can run through perl. If you
have a B<man> program but it doesn't find your modules, you'll have
-to fix your manpath. See L<perl> for details. If you have no
-system B<man> command, you might try the B<perldoc> program.
+to fix your manpath. See L<perl> for details.
=head2 Extension Modules
Extension modules are written in C (or a mix of Perl and C). They
are usually dynamically loaded into Perl if and when you need them,
-but may also be be linked in statically. Supported extension modules
+but may also be linked in statically. Supported extension modules
include Socket, Fcntl, and POSIX.
Many popular C extension modules do not come bundled (at least, not
=item Try to design the new module to be easy to extend and reuse.
-Always use B<-w>.
+Try to C<use warnings;> (or C<use warnings qw(...);>).
+Remember that you can add C<no warnings qw(...);> to individual blocks
+of code that need less warnings.
Use blessed references. Use the two argument form of bless to bless
into the class name given as the first parameter of the constructor,
Let the objects look after themselves! Generally, avoid hard-wired
class names as far as possible.
-Avoid C<$r-E<gt>Class::func()> where using C<@ISA=qw(... Class ...)> and
-C<$r-E<gt>func()> would work (see L<perlbot> for more details).
+Avoid C<< $r->Class::func() >> where using C<@ISA=qw(... Class ...)> and
+C<< $r->func() >> would work (see L<perlbot> for more details).
Use autosplit so little used or newly added functions won't be a
burden to programs that don't use them. Add test functions to
$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()>.
+e.g., C<< $obj->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.
short or common names to reduce the risk of name clashes.
Generally anything not exported is still accessible from outside the
-module using the ModuleName::item_name (or C<$blessed_ref-E<gt>method>)
+module using the ModuleName::item_name (or C<< $blessed_ref->method >>)
syntax. By convention you can use a leading underscore on names to
indicate informally that they are 'internal' and not for public use.