|
1 | 1 | Code style and linting
|
2 | 2 | ======================
|
3 | 3 |
|
4 |
| -.. TODO:: TODO |
| 4 | + |
| 5 | +Code style |
| 6 | +---------- |
| 7 | + |
| 8 | +IMASPy follows `The Black Code Style |
| 9 | +<https://black.readthedocs.io/en/stable/the_black_code_style/index.html>`_. All Python |
| 10 | +files should be formatted with the ``black`` command line tool (this is checked in |
| 11 | +:ref:`CI <ci configuration>`). |
| 12 | + |
| 13 | + |
| 14 | +Why Black? |
| 15 | +'''''''''' |
| 16 | + |
| 17 | +We use the black autoformatter, so the code style is uniform across all Python files, |
| 18 | +regardless of the developer that created the code 🙂. |
| 19 | + |
| 20 | +This improves efficiency of developers working on the project: |
| 21 | + |
| 22 | +- Uniform code style makes it easier to read, review and understand other's code. |
| 23 | +- Autoformatting code means that developers can save time and mental energy for the |
| 24 | + important matters. |
| 25 | + |
| 26 | +More reasons for using black can be found on `their website |
| 27 | +<https://black.readthedocs.io/en/stable/index.html>`_. |
| 28 | + |
| 29 | + |
| 30 | +Using Black |
| 31 | +''''''''''' |
| 32 | + |
| 33 | +The easiest way to work with Black is by using an integration with your editor. See |
| 34 | +https://black.readthedocs.io/en/stable/integrations/editors.html. |
| 35 | + |
| 36 | +You can also ``pip install black`` and run it every time before committing (manually or |
| 37 | +with pre-commit hooks): |
| 38 | + |
| 39 | +.. code-block:: console |
| 40 | +
|
| 41 | + $ black imaspy |
| 42 | + All done! ✨ 🍰 ✨ |
| 43 | + 66 files left unchanged. |
| 44 | +
|
| 45 | +
|
| 46 | +Linting |
| 47 | +------- |
| 48 | + |
| 49 | +IMASPy uses `flake8 <https://flake8.pycqa.org/en/latest/>`_ for linting (static code |
| 50 | +analysis). Flake8 should not report any violations when running it on the ``imaspy`` |
| 51 | +code base. Again, this is checked in CI. |
| 52 | + |
| 53 | +In some exceptions we can ignore a violation. For example, if a violation cannot be |
| 54 | +avoided, or fixing it would result in less readable code. This should be avoided as much |
| 55 | +as possible though. |
| 56 | + |
| 57 | + |
| 58 | +Why linting? |
| 59 | +'''''''''''' |
| 60 | + |
| 61 | +Because it results in more readable code and can prevent some types of bugs! |
| 62 | + |
| 63 | + |
| 64 | +Using flake8 |
| 65 | +'''''''''''' |
| 66 | + |
| 67 | +Again, the easiest way to work with the ``flake8`` linter is by using an integration |
| 68 | +with your editor. |
| 69 | + |
| 70 | +You can also ``pip install flake8`` and run it every time before comitting to check if |
| 71 | +your code introduces any violations: |
| 72 | + |
| 73 | +.. code-block:: console |
| 74 | +
|
| 75 | + $ flake8 imaspy |
| 76 | +
|
0 commit comments