Example of pre-commit
with codespell
#338
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Re @jpswinski!
Here is an example of using
pre-commit
with thecodespell
hook! It is just adding a workflow file in.github
and a config file at the root.The associated run in CI for this PR will show the typos found (Output here: https://github.com/ICESat2-SlideRule/sliderule/actions/runs/6385765295/job/17331180671?pr=338).
The idea behind
pre-commit
is to run static checks before anything else, and apply this automatically just before commit. It mostly serves to do static code checking and formatting (=linting), but also spell checking or environment setup (for instance, some packages likepandas
produce theirrequirements.txt
forpip
using theirenvironment.yml
fromconda
to ensure consistency! they run a script for this inpre-commit
: https://github.com/pandas-dev/pandas/blob/main/.pre-commit-config.yaml#L267).Locally, you can program it to run before commits, or run it manually this way from the package root:
pre-commit run --all
after installingpre-commit
(available onpip
orconda
)It is a great way to make a package extra-robust to errors, as the checks cover all code without requiring to be dynamically checked in the
tests/
, which is especially relevant to type checking.In Python, many projects use
flake8
+isort
for Python syntax checking (https://github.com/pycqa/flake8 ),black
for formatting (https://github.com/psf/black) andmypy
for type checking (https://github.com/python/mypy). It's a big step to usemypy
, but it saves so much effort down the line. MyPy now has a NumPy plugin, so it knows what array size + dtype has to be passed as input/output of any function, and detects that just from the code, really powerful! Butmypy
requires typing when coding in Python:The fully deterministic linters will apply modifications to the scripts automatically (formatters), and other will simply detect and propose changes (spell check, type check, etc).
I looked at some C++ projects, as I'm not too familiar for the hooks used there, and it looks like several projects are using
clang-format
for the C++ side of things, see example for GDAL here: https://github.com/OSGeo/gdal/blob/master/.pre-commit-config.yaml#L30, with a conf file here: https://github.com/OSGeo/gdal/blob/master/.clang-format.Maybe you know this tool?
A complete list of
pre-commit
hooks is available here: https://pre-commit.com/hooks.html.It would probably be a lot to start with all at once, especially the aggressive hooks (
mypy
orblack
, for instance), but the more "moderate" ones shouldn't be too much work!