Guidelines

• All submissions to the project must be released into the public domain, with no patents encumbering their use
• Please try to follow my code/formatting style. See the bottom of the page for specifics
• Keep interfaces clean and understandable
• Test suites submitted with any objects you add are appreciated, and if your patches break a test suite, update the test suite(s) in your patch
• All patches/submissions must be in Unix text format, not DOS/Windows/MacOS. Violators will be flogged
• Before using features specific to a version of Perl after 5.004, talk to Pat Gunn. For now, that version will be the base version of Perl assumed for MoLD.
• Avoid excessively unreadable language features, and when using them, be sure to comment especially well what the code does

Coding/Formatting Style

• Apart from the brackets to a global function, which may be done either way, indent with a tab a block of code in brackets, placing the brackets on their own line:
  

  while(1)
  	{
  	pop($foo, @bar);
  	print $foo . "\n";
  	}
  

• For functions, place comments on what the function is supposed to do as a comment in a blank line between the declaration and the bracket:
  

  sub gettimenice
  		# Gets the current time in a nice format, ready for printing
  {
  ...
  }
  

• Try to use variable names that are at least somewhat related to their function
• Don't use Pod documentation
• Never put brackets on the same line as their conditional or the things they enclose
• Ask before introducing a dependency on a Perl module that did not come with stock Perl 5.004
• All code (patches are expected not to break this) is expected to run with the -w flag to Perl, and generate no warnings in doing so. Builtin classes of warnings should not be disabled
• Code that must recognize what OS it is running under or other large runtime decisions must be specifically abstracted from the core of the program. Where Perl has multiple syntaxes that are compatible with all operating systems (e.g. filenames), Unix syntax will be used.