Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: 6c2edca6f0
Fetching contributors…

Cannot retrieve contributors at this time

167 lines (104 sloc) 3.845 kb

How to Code

In general, follow the languages established best practices, and fill in the gaps where there are holes.

General Guidelines

  • Style matters

    How code is aligned matters, because code is reviewed, edited, and public. Code that is uneasy to read does not align with the spirit of open source.

  • Be consistent

    If you do something a certain way, be able to justify it. Don't mix camelCase with underscore_words unless you have good reason.

  • Follow code around you

    If you don't know what you're doing try to follow what others have done.


In languages and frameworks that provide easy test-ability, write tests!

Go for 80% or more coverage, especially in the following areas:

  • privacy - e.g. test that private things are private
  • heavily used code - e.g. landing pages, library level code
  • re-opened bugs

Tests last longer than code, as they tend to define the products' functionality. They are valuable because they allow us to quickly make changes without fear of hindering functionality.

The other half of testing is continuous integration. We should be running our tests at every check in and be able to say with certainty that the code is correct to the best of our knowledge. See :ref:`ci-chapter`.


We do what others do:

  • We follow PEP8.
  • We test using which combines and pyflakes.
  • Pocoo has good guidelines as well, let's steal them.

Also, spaces matter:

  • Use 4 spaces, not 2---it increases legibility considerably.
  • Never use tabs---history has shown that we cannot handle them.

Use single quotes unless you need double (or triple) quotes:

'this is good'

'this\'s bad'

"this's good"

"this is inconsistent, but ok"

"""this's sometimes "necessary"."""

'''nobody really does this'''


Follow :ref:`python`. There are a few things in Django that will make your life easier:

Use resolve('myurl') and {{ url('myurl') }} when linking to internal URLs. This will handle hosts, relative host names, changed end points for you. It will also noticeably break so dead-links don't linger in your code.

Indentation within templates should be handled as such:

{% if indenting %}
  <p>This is how it's done</p>
{% endif %}


New web-apps should be spawned from Playdoh and existing ones should follow the spirit of Playdoh. Playdoh collects lessons that several Mozilla Django projects have learned and wraps them into a single Django project template.

In the future, much of Playdoh's moving parts (Middleware, filters, etc) will be moved into a separate library so these features won't be lost.

See :ref:`packaging`.


  • Use JSHint — it's like JSLint but a bit more reasonable. JSHint has options for assuming jQuery, node.js, and other options of use to web developers writing JavaScript.
  • Write QUnit tests when possible.
  • Do not write JS in the HTML.
  • Prefer single quotes over double.


  • Use the HTML5

  • Make sure your code validates

  • No CSS or JS in the HTML

  • Be semantic

  • Use doublequotes for attributes:

    <a href="#">Good</a>
    <a href='#'>Less Good</a>
Jump to Line
Something went wrong with that request. Please try again.