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
+portions of code via the C<use 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
=item *
-Space before the opening curly of a multiline BLOCK.
+Space before the opening curly of a multi-line BLOCK.
=item *
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:
=item *
-Line up your translations when it makes sense:
+Line up your transliterations when it makes sense:
tr [abc]
[xyz];
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
+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.