8000 DOC: Style guide could indicate formatters / pre-commit hook · Issue #21424 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

DOC: Style guide could indicate formatters / pre-commit hook #21424

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tgross35 opened this issue May 2, 2022 · 5 comments
Open

DOC: Style guide could indicate formatters / pre-commit hook #21424

tgross35 opened this issue May 2, 2022 · 5 comments

Comments

@tgross35
Copy link
tgross35 commented May 2, 2022

Issue with current documentation:

I'm working through my first issue with the project, and struggling to find information on whether there is a recommended formatter. The source currently seems to use a mix of optional styles (single vs. double quotes, backslash vs. brackets, formatting of non-python files, etc.) and I think that some more specific in the docs, possibly with recommended formatters and/or formatter config files, would help to simplify things a bit.

The only reference to style that I found was here: https://numpydoc.readthedocs.io/en/latest/format.html

Idea or request for content:

Plenty of projects use Black to format code, and I don't think that would be a bad idea here. If there are some custom style options that Numpy prefers to stick with, then something like Autopep8 or YAPF would probably be configurable to work.

A simpler option would be to add a precommit hook that handles formatting, just to be able to easier enforce consistency. Even if the hook isn't enforced in the pipeline, it would at least help give devs some direction when working locally. At a minimum, the following hooks would be quite useful:

  • Black (with line length 79 to match pycodestyle)
  • flake8, recommended in the Numpy style guide
  • trailing-whitespace
  • end-of-file-fixer
  • clang-format, to implement the config from here ENH: Add clang-format file #19754

Optionally, some other nice to have hooks would be:

  • isort
  • pretty-format-ini
  • pretty-format-toml
  • pretty-format-yaml
  • check-toml
  • check-yaml
  • fix-byte-order-marker
  • mixed-line-ending

If there is interest in this, I would be happy to submit a PR. Of course, it is possible that this has been discussed before and there's a reason it doesn't exist. I couldn't find anything in the issues list, but I figure there must be a reason why linter.py is used instead of a precommit hook.

@mattip
Copy link
Member
mattip commented May 2, 2022

There is a CI linter job that runs a script tools/linter.py. This is a comprimise solution to only check lines that have changed. The PR to add this was #18423 which was transfered from scipy scipy/scipy#11423 and based on a mailing list discussion https://mail.python.org/pipermail/scipy-dev/2020-January/023927.html.

@tgross35
Copy link
Author
tgross35 commented May 2, 2022

Thank you for the links, makes sense about the incremental changes.

If there is a goal of eventually having some sort of format, darker exists which runs black & isort only on changed lines, and can be a precommit hook or an editor plugin. There's also a way to do the same for a hook with clang-format, which would allow for your comment in #19754 (comment)

If it's not a "hard no" to have some sort of optional incremental formatter, then I'll come up with a sample config file to at least test out

@DimitriPapadopoulos
Copy link
Contributor
DimitriPapadopoulos commented May 15, 2025

Some of these suggestions have been applied incrementally:

Not done yet:

It remains unclear if there is interest in pre-commit hooks, and whether they should be enforced by pre-commit.ci or the official GitHub Action https://github.com/pre-commit/action. The latter is in maintenance mode so I wouldn't recommend it.

@jorenham
Copy link
Member

I would recommend against using pre-commit actually. See numpy/numtype#388 (comment) and scientific-python/cookie#577

@DimitriPapadopoulos
Copy link
Contributor

I'm not a huge fan of pre-commit either, for different reasons, and I have to agree the maintainer is.. difficult.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0