Page History

The backend Perl code must conform to the following style guidelines. If you find any code which doesn't conform, please fix it. These requirements are intended to maintain consistent, organized, professional code.

Indentation

Proper indentation is very important.  Just because the code lines up properly in your editor of choice, does not mean it will line up properly for someone else working on the project.  This can be very annoying.  These requirements will prevent this.

...

A mix of tabs and spaces is only acceptable preferred in order to indent sections of code which spans span multiple lines but is not an entire block between curly braces.  The following example illustrates this:

...

Comments

• Comment as much as sanely possible.
• There should always be at least 1 space between the # character and the beginning of the comment.  This makes it a little easier to read multi-line comments:
  • No:
    #Comments are your friend, they help#other developers understand your brilliance.
  • Yes:
    # Comments are your friend, they help
    # other developers understand your brilliance.

Subroutine & Variable Names

• All subroutine & variable names should be meaningful.  Don't be stingy or lazy.
• Single letter variable names should never be used unless for a loop iterator:
  • No: my $m = '00:50:56:12:88:99';
  • Yes: my $mac_address = '00:50:56:12:88:99';
  • OK: for (my $loop = 0; $loop<=10; $loop++) {
  • OK: for (my $i = 0; $i<=10; $i++) {
• Avoid abbreviations:
  • No: sub get_comp_name {
  • Yes: sub get_computer_name {
  • No: my $ip_addr;
  • Yes: my $ip_address;
• Use underscores to separate words:
  • No: sub getcomputername {
  • Yes: sub get_computer_name {
  • No: my $endtime;
  • Yes: my $end_time;
• All subroutine names should be entirely lowercase:
  • No: sub updateRequestState {
  • Yes: sub update_request_state {
• All variable names defined in subroutines should entirely lowercase:
  • No: my $requestState;
  • Yes: my $request_state;
• All class variables defined at the top of a .pm file should be entirely uppercase:
  • Yes: our $SOURCE_CONFIGURATION_DIRECTORY = "$TOOLS/Windows";
• Never mix upper and lowercase:
  • No: my $ipAddress;
  • Yes: my $ip_address;

POD Documentation

All modules and subroutines must contain a POD documentation block describing what it does. POD is "Plain Old Documentation". For more information, see:

...

#/////////////////////////////////////////////////////////////////////////////

=head2 my_subroutine_name

 Parameters  : none
 Returns     : boolean
 Description : This is what the subroutine does. These lines must be 80
               characters or less. Additional lines must be indented with
               spaces, not tabs.

=cut

sub my_subroutine_name {

}

Generating or Checking POD

There are several utilities available for generating formatted POD documentation including pod2text and pod2html.  It is a good idea to run a module through one of these utilities before committing updates.

Curly Brackets, Parenthesis

• There should be a space between every control/loop keyword and the opening parenthesis:
  • No:
    if($loop_count <= 10) {
  • Yes:
    if ($loop_count <= 10) {
  • No:
    while($loop_count <= 10) {
  • Yes:
    while ($loop_count <= 10) {

• There should be a space between every closing parenthesis and the opening curly bracket:
  • No:
    if ($loop_count <= 10){
  • Yes:
    if ($loop_count <= 10) {
  • No:
    while ($loop_count <= 10){
  • Yes:
    while ($loop_count <= 10) {

If/Else Statements

• 'else' & 'elsif' statements should be on a separate line after the previous closing curly brace:
  • No:
    if ($end_time < $now) {
       ...
    } else {
       ...
    {color:#000000}}** Yes:
    if ($end_time < $now) {
       ...
    }
    else {
       ...
    }