Development Policy

Git

Please make really sure that your commits are correct and contain the files you expect.

Commit messages

Please use relevant commit messages and don't repeat them literally if you fix a mistake in an earlier commit.

Before push

Dependencies

Please remember to update Makefile.PL (or your choice) with new modules in your code.

Perl modules

Before pushing any non-trivial changes, run

RELEASE_TESTING=1 make test

and fix any errors that show up from these tests.

Security

Files with sensitive information

This affect files with any type of password, secret token etc. Permission should be as restrictive as possible, usually just read/write for the owner of the file.

Coding Style

Variable names

Never use the same variable name for different variable types, this is really confusing.

my $wishlists = MyApp::Wishlists::wishlists_pending();
my @wishlists = map {$_->{code}} @$wishlists;

Aside from that, this example can be reduced to one line:

my @wishlists = map {$_->{code}} @${MyApp::Wishlists::wishlists_pending};

Debugging

Always include the subject of debugging in the log messsage. For example, if you dumping errors:

debug to_dumper($errors);

This might result in the following message:

debug @0.070835> $VAR1 = undef;

So other developers will have no clue when looking at the logs, please use instead:

debug "Form error: ", to_dumper($errors);

JavaScript

First of all we recommend to really use the JavaScript console.

For example, a nice way to output a Jquery DOM element is as follows:

console.log("Item foo: " + $('#foo').prop('outerHTML'));

Tests

In general successful tests should be silent - makes it easier to see what happens.

The standard POD and POD coverage tests should be author tests only, otherwise installation may fail unexpectedly.

Layout (HTML/CSS)

Add/update version numbers to style sheets after changing them. This ensure that HTML stays in sync with CSS.

<link rel="stylesheet" type="text/css" media="screen" href="/css/main.css?v=46" />

It should be clear what belongs inside the HTML, this is a really bad example:

<tr>
  <td colspan="2">bla</td>
</tr>              

Also HTML elements which are supposed to filled with content need either HTML class or id attribute.

List of files for the layout

• Tab icon

List of views for the layout

• ...

• Email receipt

• Page not found (400)

• Error (500)

• Account

  • View orders (overview + detail)

DBIC

Relationship accessor/Result names

Relationship/result names must be english words satisfying the following constraints

1. the word must be properly and unambiguously singular-and-pluralizable, while remaining colloquial english: e.g. "money" and "media" are to be avoided. Same for things like "pricing" (which while having a plural of "pricings" doesn't sound like anything anyone would say).

2. The chosen words must unambiguously refer to the problem domain; price is a valid word, because it does not have a ton of meanings, as opposed to e.g. "media"