=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.