X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlstyle.pod;h=3fb93970909dbf52e25eac33b6a0ac350d21572a;hb=4ad40acfc62db410aa4eb7654e17246f1fc97689;hp=8adb9011395b762072f9e919fcefec8397ca1f2a;hpb=54310121b442974721115f93666234a200f5c7e4;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlstyle.pod b/pod/perlstyle.pod
index 8adb901..3fb9397 100644
--- a/pod/perlstyle.pod
+++ b/pod/perlstyle.pod
@@ -10,14 +10,14 @@ 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<$^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.
+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 brace of
-a multiline BLOCK should line up with the keyword that started the construct.
+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
@@ -32,7 +32,7 @@ Opening curly on same line as keyword, if possible, otherwise line up.
 
 =item *
 
-Space before the opening curly of a multiline BLOCK.
+Space before the opening curly of a multi-line BLOCK.
 
 =item *
 
@@ -242,7 +242,7 @@ to fit on one line anyway.
 
 Always check the return codes of system calls.  Good error messages should
 go to STDERR, include which program caused the problem, what the failed
-system call and arguments were, and VERY IMPORTANT) should contain the
+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:
 
@@ -250,7 +250,7 @@ sufficient example:
 
 =item *
 
-Line up your translations when it makes sense:
+Line up your transliterations when it makes sense:
 
     tr [abc]
        [xyz];
@@ -260,9 +260,9 @@ Line up your translations when it makes sense:
 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 B<-w> in effect.  Consider giving away
-your code.  Consider changing your whole world view.  Consider... oh,
-never mind.
+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 *