2.0 KiB

Raw Permalink Blame History

StarlingX Sysinv Style Commandments

Step 1: Read the OpenStack style commandments https://docs.openstack.org/hacking/
Step 2: Read on

Sysinv Specific Commandments

Code changes which affect the sysinv REST API must also be documented in: https://docs.starlingx.io/contributor/api_contribute_guide.html

TODO vs FIXME

TODO(name): implies that something should be done (cleanup, refactoring, etc), but is expected to be functional.
FIXME(name): implies that the method/function/etc shouldn't be used until that code is resolved and bug fixed.

Logging

Use the common logging module, and ensure you getLogger:

from oslo_log import log

LOG = log.getLogger(__name__)

LOG.debug('Foobar')

AssertEqual argument order

assertEqual method's arguments should be in ('expected', 'actual') order.

Properly Calling Callables

Methods, functions and classes can specify optional parameters (with default values) using Python's keyword arg syntax. When providing a value to such a callable we prefer that the call also uses keyword arg syntax. For example:

def f(required, optional=None):
    pass

# GOOD
f(0, optional=True)

# BAD
f(0, True)

This gives us the flexibility to re-order arguments and more importantly to add new required arguments. It's also more explicit and easier to read.

Creating unit tests

For every new feature, unit tests should be created that both test and (implicitly) document the usage of said features. If submitting a patch for a bug that had no unit test, a new passing unit test should be added. If a submitted bug fix does have a unit test, be sure to add a new one that fails without the patch and passes with the patch.

All unittest classes must ultimately inherit from testtools.TestCase. In the sysinv test suite, this should be done by inheriting from sysinv.tests.base.TestCase.

2.0 KiB Raw Permalink Blame History