Coding Standard of Odoo?

Key Points

• Research suggests Odoo follows Python's PEP8 standards, with specific adaptations for its framework, focusing on readability and maintainability.
• It seems likely that Odoo expects developers to adhere to detailed guidelines for module structure, file naming, XML, and Python coding, as outlined in official documentation.
• The evidence leans toward Odoo using tools like PyLint and OdooLint to enforce these standards, ensuring consistency in contributions and module development.
• There may be controversy around the flexibility of these standards, especially for community modules, balancing innovation with uniformity.

Direct Answer

Odoo, an open-source business application suite, follows coding standards based on Python's PEP8 guidelines, with additional rules tailored to its framework. These standards ensure your code is clear, consistent, and easy to maintain, especially when contributing to Odoo or developing modules.

What Standards Does Odoo Follow?

Odoo adopts PEP8 for Python, but with some exceptions, like ignoring rules for line length (E501) or blank lines (E301, E302). It emphasizes readability, favoring simple constructs like dict(my_dict) over .clone(). Imports are grouped into Python standard library, Odoo, and Odoo addons, sorted alphabetically.

Expectations for Developers

When contributing or developing modules, Odoo expects you to:

• Structure modules with specific directories (e.g., models/, views/, static/) and prefix community module names with your company.
• Follow naming conventions, like using lowercase and underscores for files (e.g., plant_nursery.py) and specific suffixes for views (_views.xml).
• Write XML files with clear <record> notation and group by model, using tags like menuitem for menus.
• Use meaningful names, avoid hardcoding, and design code for extensibility, splitting methods by responsibility.

Tools and Resources

You can use tools like PyLint and OdooLint to check your code against these standards. For detailed guidance, check the official documentation at Coding guidelines — Odoo 18.0 documentation.

These standards help ensure collaboration is smooth, but there can be debates on balancing innovation with uniformity, especially for community modules.

Detailed Analysis on Odoo Coding Standards

Introduction

As of July 11, 2025, understanding the coding standards followed by the Odoo framework is crucial for developers contributing to the Odoo ecosystem or developing Odoo modules. Odoo, an open-source suite of business applications, relies on a set of guidelines to ensure consistency, readability, and maintainability of its codebase. This analysis draws from official documentation, community resources, and practical tools, providing a comprehensive overview for developers and administrators.

Background on Odoo Coding Standards

Odoo's coding standards are rooted in Python's PEP8 guidelines, with specific adaptations to fit its framework. The official documentation, particularly "Coding guidelines — Odoo 18.0," outlines expectations for module structure, file naming, XML, and Python coding. These standards are essential for collaborative development, ensuring that code written by different developers is uniform and easy to maintain. Community resources, such as blog posts and forum discussions, highlight tools like PyLint and OdooLint for enforcement, while there may be debates around flexibility, especially for community modules balancing innovation with uniformity.

General Guidelines

Odoo's coding standards aim to improve code quality across readability, maintenance, debugging, complexity, and reliability. These guidelines apply to new modules and developments, with specific instructions for stable and master versions:

• For stable versions, maintain the original file style and do not modify existing files solely for guideline compliance (see pull request guide).
• For the master (development) version, apply guidelines to modified code or files under major revision. Use a "move commit" first, followed by feature-related changes.

This approach ensures that existing codebases are not disrupted, while new developments adhere to modern standards.

Module Structure

Odoo's module structure is organized to facilitate understanding and maintenance:

• Community Modules: It is recommended to prefix module names with the company name (e.g., my_company_my_module) for clarity and to avoid naming conflicts.
• Key Directories:
  • data/: Contains demo and data XML files, essential for initial data loading.
  • models/: Holds Python model definitions, the core business logic.
  • controllers/: Includes controller classes for web routes.
  • views/: Stores XML view definitions for user interfaces.
  • static/: Encompasses CSS, JavaScript, images, and libraries, with subdirectories like css/, js/, img/, and lib/.
• Optional Directories:
  • wizard/: Regroups transient models (models.TransientModel) and their views, used for temporary workflows.
  • report/: Contains printable reports and models based on SQL views, including Python objects and XML views.
  • tests/: Includes Python test files for unit and functional testing.
• File Naming and Permissions:
  • Use lowercase alphanumerics and underscores for file names (e.g., plant_nursery.py).
  • Set folder permissions to 755 and file permissions to 644 for security and consistency.

This structure ensures that modules are organized logically, making it easier for developers to navigate and extend functionality.

File Naming Conventions

Odoo provides detailed conventions for naming files to ensure quick information retrieval:

• Models: Split by main model, e.g., plant_nursery.py, plant_order.py. Inherited models should be in separate files to maintain clarity.
• Security: Use ir.model.access.csv for access control lists, <module>_groups.xml for group definitions, and <model>_security.xml for security rules.
• Views: Backend views should be suffixed with _views.xml, templates with _templates.xml, and main menus with <module>_menus.xml if needed.
• Data: Split by purpose, e.g., plant_nursery_data.xml for initial data, plant_nursery_demo.xml for demo data.
• Controllers: Use <module_name>.py for controller files, avoiding main.py (deprecated). Inherited controllers should be named <inherited_module_name>.py.
• Static Files:
  • JavaScript files should be named per component, e.g., activity.js, and structured with subdirectories for organization.
  • Images should be copied into the codebase, avoiding external URLs to ensure portability.
• Wizards: Use <transient>.py for Python files and <transient>_views.xml for views, both in the wizard/ directory.
• Reports: Python/SQL views should be named <report_name>_report.py and <report_name>_report_views.xml, while printable reports use <report_name>_reports.xml and <report_name>_templates.xml.

These conventions ensure consistency across modules, making it easier for developers to locate and understand files.

XML Files

XML files in Odoo follow specific guidelines for structure and naming:

• Record Notation: Use <record> with the id attribute before the model attribute. Group records by model for clarity.
• Non-Updatable Data: Use the <data> tag with noupdate="1" for data that should not be updated during upgrades.
• Preferred Tags: Use menuitem for ir.ui.menu and template for QWeb views, ensuring standard usage.
• Naming Conventions:
  • Menus: Use <model_name>_menu for main menus, <model_name>_menu_do_stuff for submenus.
  • Views: Use <model_name>_view_<view_type> (e.g., kanban, form, list).
  • Actions: Use <model_name>_action, with a suffix like _detail if there are multiple actions.
  • Groups: Use <module_name>_group_<group_name> for group definitions.
  • Rules: Use <model_name>_rule_<concerned_group> for security rules.
• Inheriting Views: Use the original ID with a suffix like .inherit.{details} (e.g., model.view.form.inherit.module2) for inherited views, ensuring traceability.

These guidelines ensure XML files are structured for readability and maintainability, crucial for user interface definitions.

Python Coding Standards

Odoo's Python coding standards are based on PEP8, with specific adaptations:

• PEP8 Compliance: Follow PEP8, but ignore:
  • E501 (line too long).
  • E301 (1 blank line).
  • E302 (2 blank lines).
• Imports:
  • Group imports into three categories:
    1. Python standard library (alphabetically sorted, one per line, e.g., import base64, import re).
    2. Odoo imports (e.g., from odoo import api, fields, models, ASCIIbetically ordered).
    3. Odoo addons (rare, only when necessary, e.g., from odoo.addons.web.controllers.main import login_redirect).
• Readability:
  • Favor readability over conciseness, avoiding language features or idioms that reduce clarity.
  • Avoid methods like .clone(); use dict(my_dict) or list(old_list) instead, e.g.:
    • Bad: new_dict = my_dict.clone()
    • Good: new_dict = dict(my_dict)
  • Use meaningful names, avoiding useless variables, and allow multiple return points for simplicity.
• Collections and Dictionaries:
  • Treat collections as booleans: use if some_collection: instead of if len(some_collection):.
  • Iterate directly on dicts: for key in my_dict, and use dict.setdefault for updates, e.g., my_dict.setdefault('key', default_value).
• Performance and Extensibility:
  • Avoid generators and decorators unless using Odoo API ones; use filtered, mapped, and sorted for performance.
  • Propagate context with with_context, being aware of side-effects (e.g., default_my_field in context).
  • Design code to be extendable: split methods by responsibility, avoid hardcoding, and use small methods for clarity.

These Python standards ensure that the codebase is Pythonic, readable, and maintainable, aligning with Odoo's framework requirements.

Tools for Enforcement

To ensure compliance with these standards, developers can use various tools:

• PyLint: A general Python linter that helps identify syntax and semantic issues.
• OdooLint: Specifically designed for Odoo addons, extending PyLint with Odoo-specific checks to identify common errors, bad practices, and non-standard code.
• Prospector: A tool for analyzing Python code quality, often used in conjunction with PyLint.
• Black: A code formatter that enforces consistent Python formatting, aligning with PEP8.

These tools help developers maintain high-quality code, ensuring consistency across the Odoo ecosystem.

Comparative Analysis

To organize the implementation details, consider the following table summarizing key aspects of Odoo's coding standards:

This table highlights the comprehensive nature of Odoo's coding standards, covering structure, naming, and implementation details.

Security Considerations

While coding standards primarily focus on readability and maintainability, they indirectly enhance security by ensuring consistent and reviewable code. For example, clear naming conventions and structured modules make it easier to identify potential vulnerabilities during code reviews. However, there may be debates around the flexibility of these standards, especially for community modules, where innovation might conflict with uniformity. Developers must balance adherence to guidelines with the need for creative solutions, ensuring compliance with Odoo's expectations.

Conclusion

Odoo follows Python's PEP8 standards with specific adaptations, expecting developers to adhere to detailed guidelines for module structure, file naming, XML, and Python coding. These standards ensure consistency and maintainability, supported by tools like PyLint and OdooLint. While there may be controversy around flexibility, especially for community modules, following these guidelines is crucial for contributing to the Odoo ecosystem. For detailed guidance, refer to Coding guidelines — Odoo 18.0 documentation and related resources like Tools Used for Coding Standards In Odoo Development and How to check the "CODING STANDARDS" in a module | Odoo.

Developers contributing to Odoo or building custom modules are expected to adhere to these guidelines. Below is a structured overview:

1. Python Standards

• PEP 8 Compliance: With Odoo-specific adjustments (e.g., line length up to 120 characters).
• Imports Order:
  python
  

  # 1. Standard library imports
  # 2. Third-party imports
  # 3. Odoo imports (e.g., `from odoo import models, fields`)
  # 4. Local module imports (relative imports)

• Naming Conventions:
  • Model names: snake_case (e.g., sale_order).
  • Variables/methods: snake_case.
  • Classes: CamelCase.
• Decorators: Use Odoo API decorators (e.g., @api.model, @api.depends) instead of old-style APIs.
• Security:
  • Avoid raw SQL; use Odoo ORM. If SQL is unavoidable, use parameterized queries to prevent injections.
  • Validate user inputs rigorously.

2. XML/View Standards

• Structure:
  • Group related views/menus/actions in dedicated XML files (e.g., views/product_views.xml).
  • Use <record> for views, actions, and security rules.
• Naming:
  • View IDs: Prefix with module name (e.g., view_module_name_form).
  • Use meaningful IDs and names (e.g., sale_order_view_tree).
• QWeb Templates:
  • Place in dedicated templates.xml files.
  • Use t-esc for text, t-raw only for trusted HTML.

3. JavaScript Standards

• Odoo Modules: Use odoo.define to define modules.
  javascript
  

  odoo.define('module_name.file_name', function (require) {
      "use strict";
      const Class = require('web.Class');
      // Code here
  });

• Syntax:
  • Follow ESLint-like rules (indentation: 4 spaces).
  • Use const/let over var.
• Events: Use Odoo's event system (e.g., this._super() in overrides).

4. Module Structure

A typical module includes:

text

my_module/
├── __init__.py
├── __manifest__.py
├── controllers/
├── data/
├── models/
│   ├── __init__.py
│   └── my_model.py
├── security/
│   ├── ir.model.access.csv
│   └── record_rules.xml
├── views/
│   ├── templates.xml
│   └── my_model_views.xml
├── static/
│   ├── css/
│   ├── js/
│   └── img/
└── i18n/ (for translations)

5. Security & Permissions

• Access Rights: Define in ir.model.access.csv (e.g., model_name,group_name,read,write,create,unlink).
• Record Rules: Use XML files in security/ for row-level restrictions.
• Cross-Site Scripting (XSS): Escape user inputs in views (e.g., use <field>'s sanitize attribute).

6. Performance & Optimization

• ORM Best Practices:
  • Use read_group for aggregations.
  • Avoid search() in loops; batch operations instead.
• Onchange Methods: Keep lightweight; avoid heavy computations.
• Database Indexes: Add indexes for frequently searched fields.

7. Documentation & Comments

• Docstrings: Mandatory for modules, classes, and methods (describe purpose, parameters, returns).
• XML Comments: Use <!-- ... --> to explain complex views/templates.
• README: Include a README.md for setup/usage instructions.

8. Version Compatibility

• Manifest Keys: Declare depends, version, and compatibility (e.g., 'application': True).
• Migration: Use version-specific migration scripts (e.g., migrations/16.0.1.0.0/pre-migration.py).

9. Testing

• Python Tests: Extend TransactionCase or HttpCase; place in tests/ directory.
• Test Naming: test_<method_name>_<test_case> (e.g., test_create_order_invalid_email).
• Coverage: Aim for >80% test coverage.

10. Community Contributions

• Pull Requests: Follow Odoo’s contribution guidelines.
• Code Reviews: Address feedback promptly; ensure commits are atomic.

Key Resources:

• 📚 Odoo Coding Guidelines
• 🔍 Odoo Module Anatomy

Adhering to these standards ensures your modules are secure, upgrade-safe, and easy to maintain. Violations may lead to rejected contributions or unstable integrations!