In a multi-programmer environment, it is important to follow common coding guidelines to make sure the code remains maintainable.
- Write PEP 8 compatible code! This is important to have a consistent, readable codebase.
- it is not explicit in PEP8, but we like a space after a comma
- Do not use TABs. Use space characters. In Gramps we use 4 spaces for indentation. This does not mean you must set your TAB stops to 4. TABs and indents are not the same thing. Most editors have a configuration option to set indentation and TAB stops. Be careful to just set the indentation to 4, which automatically means it has to be spaces. (TABs are still necessary, in Makefiles for example, and they have to be equivalent to 8 spaces, always.) To summarize:
- uses spaces, no TABs
- indentation is 4
- TAB stops (if any) are at position 9,17,25,... (first column is 1)
- Private class functions (functions that cannot be called outside the class) should be preceded with two underscores.
- Protected functions (functions that can only be called by the class or derived classes) should be preceded with one underscore.
def __private_function(self): pass def _protected_function(self): pass
Names of callbacks should be prefixed by 'cb_'. For example,
pylint does not check that arguments are used when methods are named in this way. This is useful to avoid the
pylint warning: 'W0613: Unused argument <arg>'.
The top module is called gramps, and it has following submodules:
The other dirs should not contain code, or are for testing.
Within a submodule, only relative imports are allowed of the own submodule (so starting with . or with a module of the own directory), and absolute imports of other submodules (so starting with
files in the gen submodule are not allowed to import files from the other submodules. So
- Each class should have a simple header to help mark it in the file. This is not used for documentation - it is used to help find the class when multiple classes exist in the same file.
#------------------------------------------------------------ # # MyClass # #------------------------------------------------------------
- Python provides a docstrings to document classes and functions. If the class is a class used by others (such as the gen lib classes), the docstrings should follow the restructuredtext (rst) format. This allows us to extract API documentation using sphinx.
- Apart from adding doc strings to classes and functions, also the api generating rst files must be edited so as to extract the documentation. These files are in the docs directory, for info read the /docs/README.txt file.
Classes that are not core reusable classes do not have to follow this format (although we encourage you do), but should be documented using docstrings.
class MyClass: """ MyClass is a sample class. """ def my_function(self): """ The my_function task serves no purpose whatsoever. """ pass
pylinton your code before checking in.
- New files shall have a Pylint score of 9 or higher. New files will not be accepted if they have a Pylint score lower than 9.
- Any changes to existing files with a Pylint score lower than 9 shall not reduce the Pylint score. It is expected that over time, this policy will cause all files to eventually have a score of 9 or higher.
Note that you must run
pylint in the
gramps directory. If import errors still occur, add a PYTHONPATH. Example usage:
[email protected]:~/programs/trunk/src$ PYTHONPATH=plugins/lib/ pylint --include-ids=y --reports=y plugins/mapservices/googlemap.py
Set reports to n to have less output. Information on the meaning of codes can be found here:
- All codes, PyLint Messages: and what they're trying to tell you
- Always develop with language translation in mind
- Reduce dependencies (imports) between files.
- Think on Accessibility.