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.
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
...
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):
...
|
|
The editor's indentation with is changed to 8. | The code remains lined up properly and easy to read. |
...
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:
Code Block |
---|
#/////////////////////////////////////////////////////////////////////////////
=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 {
}
|
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.
No caps unless class var
use underscores
No caps!
Use underscores
...
if($total_hours >= 13 && $diff_hours >= 23 && $diff_minutes >= 55){