Coding Conventions
The best applications are coded properly. This sounds like an obvious statement, but by ‘properly’, mean that the code not only does its job well, but is also easy to add to, maintain and debug. For that we should follow a convention or guideline. And also ask a question yourself and make sure that your code is properly following one convention and properly documented.
1. Code lay-out
1.1 Indentation
Hanging indent :When using a hanging indent the following considerations should be applied; there should be no arguments on the first line and further indentation should be used to clearly distinguish itself as a continuation line.
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# More indentation included to distinguish this from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# Hanging indents should add a level.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
When the conditional part of an if-statement is long enough to require that it be written across multiple lines, it’s worth noting that the combination of a two character keyword (i.e. if), plus a single space, plus an opening parenthesis creates a natural 4-space indent for the subsequent lines of the multiline conditional.
1.2 Tabs or Spaces?
Spaces are the preferred indentation method.
1.3 Maximum Line Length
For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.
1.4 Should a line break before or after a binary operator?
# Yes: easy to match operators with operands
income = (gross_wages
+ taxable_interest
+ (dividends – qualified_dividends)
– ira_deduction
– student_loan_interest)
1.5 Blank Lines
Surround top-level function and class definitions with two blank lines.
Method definitions inside a class are surrounded by a single blank line.
Use blank lines in functions, sparingly, to indicate logical sections.
1.6 Source File Encoding
Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2).All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible.
1.7 Imports
should usually be on separate lines, e.g.:
Yes: import os
import sys
No: import sys, os
It is okay to say “from subprocess import Popen, PIPE”
Imports should be grouped in the following order:
Standard library imports
Related third party imports
Local application/library specific imports
2. Module level dunder names
Module level “dunders” (i.e. names with two leading and two trailing underscores) such as __all__, __author__,__version__, etc. should be placed after the module docstring but before any import statements except from __future__imports. Python mandates that future-imports must appear in the module before any other code except docstrings.
3. String Quotes
When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.
4. Whitespace in Expressions and Statements
Avoid so many whitespace, like after or before comma, after brackets etc.
Yes: a. spam(1)
No: spam (1)
b. Yes: [“base”, ‘mail’, ‘sale’, ‘account_voucher’, ‘account’]
No: [“base”,’mail’,’sale’,’account_voucher’,’account’]
One space should be there after comma
More than one space around an assignment (or other) operator to align it with another.
Yes:
x = 1
y = 2
long_variable = 3
No:
x = 1
y = 2
5. When to use trailing commas
Trailing commas are usually optional, except they are mandatory when making a tuple of one element (and in Python 2 they have semantics for the print statement). For clarity, it is recommended to surround the latter in (technically redundant) parentheses.
Yes:
FILES = (‘setup.cfg’,)
FILES = [
‘setup.cfg’,
‘tox.ini’,
]
initialize(FILES,
error=True,
)
6. Comments
- Always make a priority of keeping the comments up-to-date when the code changes!
- complete sentences,
- first word should be capitalized(exception: identifier),
- each sentence should end in a period, means the sign full stop .
- please write your comments in English,unless u r sure that code will never read by other language people
- inline comments : comment on the same line as a statement
- start with a # and a single space
7. Naming Conventions
When writing any fields or descriptions in the python ,make sure whatever coming in the client side is of CORRECT SP
When using abbreviations in CapWords, capitalize all the letters of the abbreviation. Thus HTTP Server Error is better than HttpServerError
Never use the characters ‘l’ (lowercase letter el), ‘O’ (uppercase letter oh), or ‘I’ uppercase letter eye) as single character variable names.In some fonts, these characters are indistinguishable from the numerals one and zero. When tempted to use ‘l’, use ‘L’ instead.
Package & module Names
* Modules should have short, all-lowercase names.
* Underscores can be used in the module name if it improves readability.
* Python packages should also have short, all-lowercase names,
1. The name of the module are all lowercase, each word separated by underscore. Start always by the most relevant words, which are preferably names of others modules on which it depends.
2. Add a description to the New Custom Class file we create in modules
#———————————————————-
# Stock Location
#———————————————————-
class stock_location(osv.osv):
stock_location()
3. Avoid whitespace, like at the line end or like after comma (Trailing whitespace).
4. Exactly one space required after comma in python files
5. No space allowed around odoo defined keyword argument assignment like context=None, context=context, required=True, * readonly=True etc which is given along with field declaration or function call(def ….).
6. Exactly one space required before/after assignment
7. No space allowed before colon
8. No space allowed before & after bracket
9. If brackets don’t hold any data , don’t keep space, keep it as empty.
Comments
: ".
Leave a Reply