..note:: View name use dot notation ``my.model.view_type`` or ``my.model.view_type.inherit`` instead of *"This is the form view of My Model"*.
Inherited XML
~~~~~~~~~~~~~
The naming pattern of inherited view is *<base_view>_inherit_<current_module_name>*. A module can extend a view only one time, suffix the orginal name with *_inherit_<current_module_name>*, where *current_module_name* is the technical name of the module extending the view.
Using a linter can help to see syntax and semantic warning or error. Odoo Source Code try to respect Python standard, but some of them can be ignored.
- E501: line too long
- E301: expected 1 blank line, found 0
- E302: expected 2 blank lines, found 1
- E126: continuation line over-indented for hanging indent
- E123: closing bracket does not match indentation of opening bracket's line
- E127: continuation line over-indented for visual indent
- E128: continuation line under-indented for visual indent
- E265: block comment should start with '# '
Imports
-------
The imports are ordered as
#. Externals libs (One per line sorted and splitted in python stdlib)
#. Imports of ``openerp``
#. Imports from Odoo modules (rarely, and only if necessary)
Inside these 3 groups, the imported lines are alphabetically sorted.
..code-block:: python
# 1 : imports of python lib
import base64
import re
import time
# 2 : imports of openerp
import openerp
from openerp import api, fields, models # alphabetically ordered
from openerp.tools.safe_eval import safe_eval as eval
from openerp.tools.translate import _
# 3 : imports from odoo modules
from openerp.addons.website.models.website import slug
from openerp.addons.web.controllers.main import login_redirect
Idioms
-------
- Prefer ``%`` over ``.format()``, prefer ``%(varname)`` instead of position (This is better for translation)
- Try to avoid generators and decorators
- Always favor *Readability* over *conciseness* or using the language features or idioms.
- Use list comprehension, dict comprehension, and basic manipulation using ``map``, ``filter``, ``sum``, ... They make the code easier to read.
- The same applies for recordset methods : use ``filtered``, ``mapped``, ``sorted``, ...
- Each python file should have ``# -*- coding: utf-8 -*-`` as first line
- Use the ``UserError`` defined in ``openerp.exceptions`` instead of overriding ``Warning``, or find a more appropriate exception in *exceptions.py*
- Document your code (docstring on methods, simple comments for the tricky part of the code)
- Use meaningful variable/class/method names
Symbols
-------
- Odoo Python Class : use camelcase for code in api v8, underscore lowercase notation for old api.
..code-block:: python
class AccountInvoice(models.Model):
...
class account_invoice(osv.osv):
...
- Variable name :
- use camelcase for model variable
- use underscore lowercase notation for common variable.
- since new API works with record or recordset instead of id list, don't suffix variable name with *_id* or *_ids* if they not contain id or list of id.
..code-block:: python
ResPartner = self.env['res.partner']
partners = ResPartner.browse(ids)
partner_id = partners[0].id
-``One2Many`` and ``Many2Many`` fields should always have *_ids* as suffix (example: sale_order_line_ids)
-``Many2One`` fields should have *_id* as suffix (example : partner_id, user_id, ...)
- Method conventions
- Compute Field : the compute method pattern is *_compute_<field_name>*
- Search method : the search method pattern is *_search_<field_name>*
- Default method : the default method pattern is *_default_<field_name>*
- Onchange method : the onchange method pattern is *_onchange_<field_name>*
- Constraint method : the constraint method pattern is *_check_<constraint_name>*
- Action method : an object action method is prefix with *action_*. Its decorator is ``@api.multi``, but since it use only one record, add ``self.ensure_one()`` at the beginning of the method.
-``use strict;`` is recommended for all javascript files
- Use a linter (jshint, ...)
- Never add minified Javascript Libraries
- Use camelcase for class declaration
**For CSS :**
- Prefix all your class with *o_<module_name>* where *module_name* is the technical name of the module ('sale', 'im_chat', ...) or the main route reserved by the module (for website module mainly, i.e. : 'o_forum' for website_forum module). The only exception for this rule is the webclient : it simply use *o_* prefix.
- Avoid using id
- Use bootstrap native class
- Use underscore lowercase notation to name class
Git
===
Commit message
--------------
Prefix your commit with
-**[IMP]** for improvements
-**[FIX]** for bug fixes
-**[REF]** for refactoring
-**[ADD]** for adding new resources
-**[REM]** for removing of resources
-**[MERGE]** for merge commits (only for forward/back-port)
-**[CLA]** for signing the Odoo Individual Contributor License
Then, in the message itself, specify the part of the code impacted by your changes (module name, lib, transversal object, ...) and a description of the changes.
- Always put meaning full commit message: commit message should be
self explanatory (long enough) including the name of the module that
has been changed and the reason behind that change. Do not use
single words like "bugfix" or "improvements".
- Avoid commits which simultaneously impacts lots of modules. Try to
splits into different commits where impacted modules are different
(It will be helpful when we are going to revert that module