whitespace and readabiliti nits in the pods (from Michael G Schwern

and Robin Barker)

p4raw-id: //depot/perl@5493

1 files changed, 4 insertions, 4 deletions

diff --git a/pod/perlmodlib.pod b/pod/perlmodlib.pod
index f4331c3324..38044c9157 100644
--- a/pod/perlmodlib.pod
+++ b/pod/perlmodlib.pod
@@ -1150,8 +1150,8 @@ Generally you can delete the C<eq 'FOO'> part with no harm at all.
 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
@@ -1208,7 +1208,7 @@ or nature of a variable. For example:
  $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.
@@ -1224,7 +1224,7 @@ export try to use @EXPORT_OK in preference to @EXPORT and avoid
 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.