Click above to get retro games delivered to your door ever month!

     Style

     Each programmer will, of course, have his or her own prefer-
     ences  in  regards to formatting, but there are some general
     guidelines that will make your programs easier to read.

     1.  Just because you  CAN  do  something  a  particular  way
         doesn't  mean  that  you SHOULD do it that way.  Perl is
         designed to give you several ways  to  do  anything,  so
         consider picking the most readable one.  For instance

              open(FOO,$foo) || die "Can't open $foo: $!";

         is better than

              die "Can't open $foo: $!" unless open(FOO,$foo);

         because the second way  hides  the  main  point  of  the
         statement in a modifier.  On the other hand

              print "Starting analysis\n" if $verbose;

         is better than

              $verbose && print "Starting analysis\n";

         since the main point isn't whether the user typed -v  or
         not.

         Similarly, just because  an  operator  lets  you  assume
         default arguments doesn't mean that you have to make use
         of the defaults.  The defaults are there for  lazy  sys-
         tems programmers writing one-shot programs.  If you want
         your program to  be  readable,  consider  supplying  the
         argument.

         Along  the  same  lines,  just  because  you  can   omit
         parentheses  in  many places doesn't mean that you ought
         to:

              return print reverse sort num values array;
              return print(reverse(sort num (values(%array))));

         When in doubt, parenthesize.  At the very least it  will
         let some poor schmuck bounce on the % key in vi.

         Even if you aren't in doubt, consider the mental welfare
         of  the  person  who has to maintain the code after you,
         and who will probably put parens in the wrong place.

     2.  Don't go through silly contortions to exit a loop at the
         top  or the bottom, when perl provides the "last" opera-
         tor so you can exit in the middle.  Just  outdent  it  a
         little to make it more visible:

             line:
              for (;;) {
                  statements;
              last line if $foo;
                  next line if /^#/;
                  statements;
              }


     3.  Don't be afraid to use  loop  labels--they're  there  to
         enhance readability as well as to allow multi-level loop
         breaks.  See last example.

     4.  For portability, when using features  that  may  not  be
         implemented  on  every machine, test the construct in an
         eval to see if it fails.  If you know  what  version  or
         patchlevel a particular feature was implemented, you can
         test $] to see if it will be there.

     5.  Choose mnemonic identifiers.

     6.  Be consistent.