123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116 |
- # Code Style
- The Synapse codebase uses a number of code formatting tools in order to
- quickly and automatically check for formatting (and sometimes logical) errors
- in code.
- The necessary tools are detailed below.
- ## Formatting tools
- The Synapse codebase uses [black](https://pypi.org/project/black/) as an
- opinionated code formatter, ensuring all comitted code is properly
- formatted.
- First install ``black`` with::
- pip install --upgrade black
- Have ``black`` auto-format your code (it shouldn't change any
- functionality) with::
- black . --exclude="\.tox|build|env"
- - **flake8**
- ``flake8`` is a code checking tool. We require code to pass ``flake8`` before being merged into the codebase.
- Install ``flake8`` with::
- pip install --upgrade flake8
- Check all application and test code with::
- flake8 synapse tests
- - **isort**
- ``isort`` ensures imports are nicely formatted, and can suggest and
- auto-fix issues such as double-importing.
- Install ``isort`` with::
- pip install --upgrade isort
- Auto-fix imports with::
- isort -rc synapse tests
- ``-rc`` means to recursively search the given directories.
- It's worth noting that modern IDEs and text editors can run these tools
- automatically on save. It may be worth looking into whether this
- functionality is supported in your editor for a more convenient development
- workflow. It is not, however, recommended to run ``flake8`` on save as it
- takes a while and is very resource intensive.
- ## General rules
- - **Naming**:
- - Use camel case for class and type names
- - Use underscores for functions and variables.
- - Use double quotes ``"foo"`` rather than single quotes ``'foo'``.
- - **Comments**: should follow the `google code style
- <http://google.github.io/styleguide/pyguide.html?showone=Comments#Comments>`_.
- This is so that we can generate documentation with `sphinx
- <http://sphinxcontrib-napoleon.readthedocs.org/en/latest/>`_. See the
- `examples
- <http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html>`_
- in the sphinx documentation.
- - **Imports**:
- - Prefer to import classes and functions rather than packages or modules.
- Example::
- from synapse.types import UserID
- ...
- user_id = UserID(local, server)
- is preferred over::
- from synapse import types
- ...
- user_id = types.UserID(local, server)
- (or any other variant).
- This goes against the advice in the Google style guide, but it means that
- errors in the name are caught early (at import time).
- - Multiple imports from the same package can be combined onto one line::
- from synapse.types import GroupID, RoomID, UserID
- An effort should be made to keep the individual imports in alphabetical
- order.
- If the list becomes long, wrap it with parentheses and split it over
- multiple lines.
- - As per `PEP-8 <https://www.python.org/dev/peps/pep-0008/#imports>`_,
- imports should be grouped in the following order, with a blank line between
- each group:
- 1. standard library imports
- 2. related third party imports
- 3. local application/library specific imports
- - Imports within each group should be sorted alphabetically by module name.
- - Avoid wildcard imports (``from synapse.types import *``) and relative
- imports (``from .types import UserID``).
|