code_style.rst 3.3 KB

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