search

biotite-dev / biotite

A comprehensive library for computational molecular biology
https://www.biotite-python.org
BSD 3-Clause "New" or "Revised" License
581 stars 92 forks source link

Adopt a code formatter and linter #590

Open 0ut0fcontrol opened 3 weeks ago

0ut0fcontrol commented 3 weeks ago

black? or yapf?

If not specified, I recommend black.

padix-key commented 3 weeks ago

I lean towards ruff due to its speed and high number of supported rules than can be configured (even the black format). Furthermore, it can be used both as formatter and linter.

For legacy reasons the project currently does not enforce a formatter at all. However, in my opinion it would make sense to introduce a formatter rather sooner than later. We would need to agree on the following points:

  1. Which formatter/linter do we want to use?
  2. Which line limit do we want? Currently we use 79 as recommended in [PEP 8]() however, black/ruff use 88 by default.
  3. How do we want implement it? Either we merge a gigantic PR reformatting the entire codebase or we expect the contributors to only reformat files changed in their commits. The CI needs to be configured accordingly: Either the linter is applied to the entire code or only on changed files.
Croydon-Brixton commented 3 weeks ago

I had good experiences with ruff. And I'd personally go with one full reformat of the code-base once, and requiring any new commits to be formatted correctly. A starting point could be to first only use ruff format (which will likely lead to the most changes) and add the ruff linting later

ruff format .  # only changes the formatting, no linting
ruff check --fix .  # this lints & fixes, we could start adding that in later, depending on how many lint issues we find (fix tries to autofix many)