You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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.

Tabs should be used to indent all code blocks.  Spaces should never be used to indent code blocks.  Mixing tabs and spaces results in misaligned code blocks for other developers who prefer different indentation settings.  Consider the following code block which is indented with all tabs (shown with and without whitespaces):

Indented properly with tabs.
Indentation width set to 3.
Whitespaces shown.

Code is lined up properl.

Indentation width set to 8.
Code remains lined up properly.

Now consider a situation where another developer is using an editor which is configured to indent using spaces by default.  The developer makes changes to 1 of the lines:

Indented incorrectly with a mix of
tabs and spaces.

Code appears lined up to the
developer who messed up the
indentation.

Code is not lined up for other
developers.

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

Everything in the notify command is indented with a single tab.
The message is broken up into multiple lines for readability.
Each line of the message is indented with spaces to make it line up with the first line.

Code is lined up properly and easy to read.

The editor's indentation with is changed to 8.
The only shifts are reflected in the tabs.

The code remains lined up properly and easy to read.

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:

What is POD?: http://en.wikipedia.org/wiki/Plain_Old_Documentation
POD syntax guide: http://search.cpan.org/dist/perl/pod/perlpod.pod

Each subroutine should begin with a POD block with the following format:

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

=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 {
         ...
      }
  • No labels