CI: yesqa & mdformat

* add & apply yesqa
* add & apply mdformat

.github/CODE_OF_CONDUCT.md

@@ -10,19 +10,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
 
 Examples of behavior that contributes to creating a positive environment include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 
@@ -42,5 +42,5 @@ Project maintainers who do not follow or enforce the Code of Conduct in good fai
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+This Code of Conduct is adapted from the \[Contributor Covenant\]\[homepage\], version 1.4,
 available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

.github/CONTRIBUTING.md

@@ -7,77 +7,86 @@ Developing Open Source is great fun! =)
 Here's the long and short of it:
 
 1. Develop your contribution:
-   * Pull the latest changes from upstream::
+
+   - Pull the latest changes from upstream::
+
    ```
       git checkout master
       git pull upstream master
    ```
-   * Create a branch for the feature you want to work on. Since the branch name will appear in the merge message, use a sensible name such as 'transform-speedups'::
+
+   - Create a branch for the feature you want to work on. Since the branch name will appear in the merge message, use a sensible name such as 'transform-speedups'::
      ```
       git checkout -b transform-speedups
      ```
-   * Commit locally as you progress (``git add`` and ``git commit``)
+   - Commit locally as you progress (`git add` and `git commit`)
+
 1. To submit your contribution:
 
-   * Push your changes back to your fork on GitHub::
+   - Push your changes back to your fork on GitHub::
      ```
       git push origin transform-speedups
      ```
-   * Enter your GitHub username and password (repeat contributors or advanced users can remove this step by connecting to GitHub with SSH. See detailed instructions below if desired).
-   * Go to GitHub. The new branch will show up with a green Pull Request  button - click it.
+   - Enter your GitHub username and password (repeat contributors or advanced users can remove this step by connecting to GitHub with SSH. See detailed instructions below if desired).
+   - Go to GitHub. The new branch will show up with a green Pull Request  button - click it.
+
 1. Review process:
-   * Reviewers (the other developers and interested community members) will write inline and/or general comments on your Pull Request (PR) to help you improve its implementation, documentation and style.  Every single developer working on the project has their code reviewed, and we've come to see it as friendly conversation from which we all learn and the overall code quality benefits.  Therefore, please don't let the review discourage you from contributing: its only aim is to improve the quality of project, not to criticize (we are, after all, very grateful for the time you're donating!).
-   * To update your pull request, make your changes on your local repository and commit. As soon as those changes are pushed up (to the same branch as before) the pull request will update automatically.
-   * `Travis-CI <http://travis-ci.org/>`__, a continuous integration service, is triggered after each Pull Request update to build the code, run unit tests, measure code coverage and check coding style (PEP8) of your branch. The Travis tests must pass before your PR can be merged. If Travis fails, you can find out why by clicking on the "failed" icon (red cross) and inspecting the build and test log.
-   * A pull request must be approved by two core team members before merging.
 
-## Guidelines
+   - Reviewers (the other developers and interested community members) will write inline and/or general comments on your Pull Request (PR) to help you improve its implementation, documentation and style.  Every single developer working on the project has their code reviewed, and we've come to see it as friendly conversation from which we all learn and the overall code quality benefits.  Therefore, please don't let the review discourage you from contributing: its only aim is to improve the quality of project, not to criticize (we are, after all, very grateful for the time you're donating!).
+   - To update your pull request, make your changes on your local repository and commit. As soon as those changes are pushed up (to the same branch as before) the pull request will update automatically.
+   - `Travis-CI <http://travis-ci.org/>`\_\_, a continuous integration service, is triggered after each Pull Request update to build the code, run unit tests, measure code coverage and check coding style (PEP8) of your branch. The Travis tests must pass before your PR can be merged. If Travis fails, you can find out why by clicking on the "failed" icon (red cross) and inspecting the build and test log.
+   - A pull request must be approved by two core team members before merging.
 
-* All code should have tests (see `test coverage`_ below for more details).
-* All code should be documented, to the same
-  `standard <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard>`_ as NumPy and SciPy.
-* For new functionality, always add an example to the gallery.
-* No changes are ever committed without review and approval by two core team members. **Never merge your own pull request.**
-* Examples in the gallery should have a maximum figure width of 8 inches.
+## Guidelines
 
+- All code should have tests (see `test coverage`\_ below for more details).
+- All code should be documented, to the same
+  `standard <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard>`\_ as NumPy and SciPy.
+- For new functionality, always add an example to the gallery.
+- No changes are ever committed without review and approval by two core team members. **Never merge your own pull request.**
+- Examples in the gallery should have a maximum figure width of 8 inches.
 
 ## Stylistic Guidelines
 
-* Set up your editor to remove trailing whitespace.  Follow `PEP08 <http://www.python.org/dev/peps/pep-0008/>`__.  Check code with pyflakes / flake8.
-* Use numpy data types instead of strings (``np.uint8`` instead of ``"uint8"``).
-* Use the following import conventions::
+- Set up your editor to remove trailing whitespace.  Follow `PEP08 <http://www.python.org/dev/peps/pep-0008/>`\_\_.  Check code with pyflakes / flake8.
+- Use numpy data types instead of strings (`np.uint8` instead of `"uint8"`).
+- Use the following import conventions::
   ```
    import numpy as np
    import matplotlib.pyplot as plt
    from scipy import ndimage as ndi
 
    cimport numpy as cnp  # in Cython code
   ```
-* When documenting array parameters, use ``image : (M, N) ndarray`` and then refer to ``M`` and ``N`` in the docstring, if necessary.
-* Refer to array dimensions as (plane), row, column, not as x, y, z. See :ref:`Coordinate conventions <numpy-images-coordinate-conventions>` in the user guide for more information.
-* Functions should support all input image dtypes.  Use utility functions such as ``img_as_float`` to help convert to an appropriate type.  The output format can be whatever is most efficient.  This allows us to string together several functions into a pipeline
-* Use ``Py_ssize_t`` as data type for all indexing, shape and size variables in C/C++ and Cython code.
-* Wrap Cython code in a pure Python function, which defines the API. This improves compatibility with code introspection tools, which are often not aware of Cython code.
-* For Cython functions, release the GIL whenever possible, using ``with nogil:``.
-
+- When documenting array parameters, use `image : (M, N) ndarray` and then refer to `M` and `N` in the docstring, if necessary.
+- Refer to array dimensions as (plane), row, column, not as x, y, z. See :ref:`Coordinate conventions <numpy-images-coordinate-conventions>` in the user guide for more information.
+- Functions should support all input image dtypes.  Use utility functions such as `img_as_float` to help convert to an appropriate type.  The output format can be whatever is most efficient.  This allows us to string together several functions into a pipeline
+- Use `Py_ssize_t` as data type for all indexing, shape and size variables in C/C++ and Cython code.
+- Wrap Cython code in a pure Python function, which defines the API. This improves compatibility with code introspection tools, which are often not aware of Cython code.
+- For Cython functions, release the GIL whenever possible, using `with nogil:`.
 
 ## Testing
 
 This package has an extensive test suite that ensures correct execution on your system.  The test suite has to pass before a pull request can be merged, and tests should be added to cover any modifications to the code base.
 
-We make use of the `pytest <https://docs.pytest.org/en/latest/>`__ testing framework, with tests located in the various ``tests`` folders.
+We make use of the `pytest <https://docs.pytest.org/en/latest/>`\_\_ testing framework, with tests located in the various `tests` folders.
 
-To use ``pytest``, ensure that Cython extensions are built and that
+To use `pytest`, ensure that Cython extensions are built and that
 the library is installed in development mode::
+
 ```
     $ pip install -e .
 ```
+
 Now, run all tests using::
+
 ```
     $ pytest -v pyImSegm
 ```
-Use ``--doctest-modules`` to run doctests.
+
+Use `--doctest-modules` to run doctests.
 For example, run all tests and all doctests using::
+
 ```
     $ pytest -v --doctest-modules --with-xunit --with-coverage pyImSegm
 ```
@@ -86,12 +95,15 @@ For example, run all tests and all doctests using::
 
 Tests for a module should ideally cover all code in that module, i.e., statement coverage should be at 100%.
 
-To measure the test coverage, install `pytest-cov <http://pytest-cov.readthedocs.io/en/latest/>`__ (using ``easy_install pytest-cov``) and then run::
+To measure the test coverage, install `pytest-cov <http://pytest-cov.readthedocs.io/en/latest/>`\_\_ (using `easy_install pytest-cov`) and then run::
+
 ```
   $ coverage report
 ```
+
 This will print a report with one line for each file in `imsegm`,
 detailing the test coverage::
+
 ```
   Name                             Stmts   Exec  Cover   Missing
   --------------------------------------------------------------
@@ -102,4 +114,4 @@ detailing the test coverage::
 
 ## Bugs
 
-Please `report bugs on GitHub <https://github.com/Borda/pyImSegm/issues>`_.
+Please `report bugs on GitHub <https://github.com/Borda/pyImSegm/issues>`\_.

.github/ISSUE_TEMPLATE/Bug_report.md

@@ -1,19 +1,20 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-
 ---
 
 ## Description
-_[Please provide a general introduction to the issue/proposal.]_
 
-_[If reporting a bug, attach the entire traceback from Python.]_
+_\[Please provide a general introduction to the issue/proposal.\]_
 
-_[If proposing an enhancement/new feature, provide links to related articles, reference examples, etc.]_
+_\[If reporting a bug, attach the entire traceback from Python.\]_
 
+_\[If proposing an enhancement/new feature, provide links to related articles, reference examples, etc.\]_
 
 ## Way to reproduce
-_[If reporting a bug, please include the following important information:]_
+
+_\[If reporting a bug, please include the following important information:\]_
+
 - [ ] Code example
 - [ ] Relevant images (if any)
 - [ ] Operating system and version

.github/ISSUE_TEMPLATE/Feature_request.md

@@ -1,21 +1,20 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-
 ---
 
 **Is your feature request related to a problem? Please describe.**
 
-_[A clear and concise description of what the problem is. Ex. I'm always frustrated when ...]_
+_\[A clear and concise description of what the problem is. Ex. I'm always frustrated when ...\]_
 
 **Describe the solution you'd like**
 
-_[A clear and concise description of what you want to happen.]_
+_\[A clear and concise description of what you want to happen.\]_
 
 **Describe alternatives you've considered**
 
-_[A clear and concise description of any alternative solutions or features you've considered.]_
+_\[A clear and concise description of any alternative solutions or features you've considered.\]_
 
 **Additional context**
 
-_[Add any other context or screenshots about the feature request here.]_
+_\[Add any other context or screenshots about the feature request here.\]_

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 # Description
 
-_[Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.]_
+_\[Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.\]_
 
 Fixes # (issue)
 
@@ -15,16 +15,16 @@ Please delete options that are not relevant.
 
 # How Has This Been Tested?
 
-_[Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration]_
+_\[Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration\]_
 
 - [ ] Test A
 - [ ] Test B
 
 **Test Configuration**:
-* Firmware version:
-* Hardware:
-* Toolchain:
-* SDK:
+
+- Firmware version:
+- Hardware:
+- Toolchain:
 
 # Checklist:
 

.pre-commit-config.yaml

@@ -37,6 +37,20 @@ repos:
         language: python
         require_serial: false
 
+  - repo: https://github.com/executablebooks/mdformat
+    rev: 0.7.7
+    hooks:
+      - id: mdformat
+        additional_dependencies:
+          - mdformat-gfm
+          - mdformat-black
+          - mdformat_frontmatter
+
+  - repo: https://github.com/asottile/yesqa
+    rev: v1.2.3
+    hooks:
+      - id: yesqa
+
   - repo: https://github.com/PyCQA/flake8
     rev: 3.9.2
     hooks: