Coding Guidelines

This list is populated incrementally by the OpenERP Quality Team as part of the code review process. It contains a set of OpenERP specific good/bad practices, as well as a selection of more generic Python coding recommendations.

Both sections are a MUST READ for every OpenERP developer and contributor.

As an introductory rule, you should always keep in mind the following:

Every line you write will be written only once, but read many times by others (including yourself)

At the risk of stating the obvious, this means that while following the other guidelines, you should always use your best judgment in order to achieve the best readability. And if writing readable code requires an additional effort, it’s worth it a thousand times.

• 1   Python style guide
  • 1.1   magic methods
  • 1.2   .clone()
  • 1.3   the “clone and update”
  • 1.4   “manual update”
  • 1.5   Java dictionary creation
  • 1.6   “temporary kwargs”
  • 1.7   deprecated methods (formally or informally)
  • 1.8   useless intermediate variables
  • 1.9   3 strikes, and the code’s out
  • 1.10   Multiple return points are OK, when they’re simpler
  • 1.11   Try to avoid type-testing
  • 1.12   Don’t use type if you already know what the type you want is
  • 1.13   But really, if you need type testing just use the tools python provides
  • 1.14   Don’t create functions just to call callables
  • 1.15   Know your builtins
  • 1.16   Learn list comprehensions
  • 1.17   Learn your standard library
  • 1.18   Collections are booleans too
  • 1.19   You can append a single object to a list, it’s ok
  • 1.20   Add lists into bigger lists
  • 1.21   Learn your standard library (2)
  • 1.22   Iterate on iterables
  • 1.23   Chaining calls is ok, as long as you don’t abuse it (too much)
  • 1.24   Use dict.setdefault
  • 1.25   Use constants and avoid magic numbers
• 2   OpenERP Specific Guidelines
  • 2.1   Bazaar is your historian
  • 2.2   Call your fish a fish
  • 2.3   Do not bypass the ORM
  • 2.4   No SQL injections, please!
  • 2.5   Factor out the code
  • 2.6   The infamous context
  • 2.7   There is better than lambda, sometimes
  • 2.8   Keep your methods short/simple when possible
  • 2.9   Never commit the transaction
  • 2.10   Use the gettext method correctly
• 3   Automated YAML Tests Guideline
  • 3.1   Syntax
  • 3.2   Tests are run on the server side
  • 3.3   Be precise about the goal of the test
  • 3.4   Avoid relying on data that can be changed by the user before launching the test
  • 3.5   Write things in test that can be easily tested by the YAML system
  • 3.6   Avoid relying on existing demo data if the user can change it.
  • 3.7   Don’t check the full text of an exception
  • 3.8   Be more functional, explain what the user means to do, not where she clicks
  • 3.9   You can use “onchange” calls in your tests, to simulate the client interface