Changes

Jump to: navigation, search

Programming guidelines

1,635 bytes added, 03:06, 5 September 2007
New page: Category:Developers/General As more and more people start editing the code, we need to establish a few guidelines to make sure the code remains maintainable. * Class headers. Each c...
[[Category:Developers/General]]

As more and more people start editing the code, we need to establish a few guidelines to make sure the code remains maintainable.

* Class headers. 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.
<code>
#------------------------------------------------------------
#
# MyClass
#
#------------------------------------------------------------
</code>
* Docstrings. Python provides a docstrings to document classes and functions. If the class is a class used by others (such as the RelLib classes), the docstrings should follow the [http://epydoc.sourceforge.net/manual-epytext.html epydoc] format. This allows us to extract [http://gramps-project.org/api3 API] documentation. Classes that are not core reusable classes do not have to follow this format, but should be documented using docstrings.
<code>
class MyClass:
"""
MyClass is a sample class.
"""

def my_function(self):
"""
The my_function task serves no purpose whatsoever.
"""
pass
</code>
* 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.
<code>
def __private_function(self):
pass

def _protected_function(self):
pass
</code>
* Run <code>pylint</code> on your code before checking in, reasonably cleaning up the code.

Navigation menu