Coding standards

Basic stuff

First solve bugs then add features

Bug fixes are more important then new features.

Code Reviews

Every story is created in it’s own branch. Person developing code then adds pull request. This pull request must be accepted by someone else.

When asigning someone with a code-review, please mark your story as In Review and assign it to this person in JIRA.

Meaningfull commit messages

Use meaningfull commit messages. Please reference JIRA issue if appropriate.

Documentation

For now code is fairly undocumented, which is bad.

Every class, and public function needs a proper docstring. These docstrings are in sphinx format. We’ll use autodoc to extract documentation from docstrings.

Unittests

Aim for 100% unittest coverage (for changed code).

Time logging

Please log time spent on developing this application. I need this information for political reasons (people at HQ don’t have idea how much value we bring in terms of free (as in beer) software).

Django stuff

• Prefer class based views to function ones.

• Even better: use class based generic views.

• Try to keep inter application dependencies to minimum
• Separate scout code with generic code

Named urls

All urls should be named and referenced only by its name and application namespace.

There is no clearly defined convention for naming urls in Django. Even across documentation there are different standards. In Drigan, we have determined some simple url-naming rules:

• Try to keep the url name short and simple

• Always use hyphen (-) to separate words

• Use this set of words in a correct place to describe actions: * sufixes:

  • list (not index)
  • detail

  • prefixes: * create * update * delete

Furthermore, always specify application namespace in urls configuration and always use this namespace to reverse urls, eg.:

url(r"^pattern/", include('my_super_app.urls', app_name='my_super_app'))

And then when you reverse urls from this app:

reverse("my_supper_app:view-name")