in pandas we did a one time conversion to using black (a while ago) for python (and recently added a cython formatter); we do also have automatic c/cpp linters as well we have precommit rules to enforce this (and runs on ci) since then we don’t have discussions about formatting anymore :) would encourage numpy to do the same Jeff
On Nov 14, 2021, at 2:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Nov 14, 2021 at 11:40 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Nov 14, 2021 at 6:14 PM Charles R Harris <charlesr.harris@gmail.com> wrote: Hi All,
This post is for discussing the automatic code formatters for C/C++/*.py that are now available. The current options, as I see them, are clang-format (C/C++) and black (*.py, *.pyi, etc). Neither is perfect to my eye, but I think they are good enough at this point and would reduce amount of style nitpicking.
clang-format
There is already a '.clang-format' file in the numpy repository. The main drawbacks that I see are: no automatic spacing between function definitions, all operators, including '*' and '/', get spaces around them, no extra indenting of continued 'if' conditions, the order of includes is alphabetical within groups. The groups are currently defined in the 'clang-format' file, but there may still be problems with include order that we will need to fix. I think those can be lived with. The results are good enough that I think it can replace the official C coding style for most things. The maximum line length is currently 79 characters.
black
The black formatter is much improved in its latest version and I think good enough to start using. The main drawbacks that I see are: all operators, including '*' and '/', get spaces around them, very long strings are not broken into multiple lines, lists, tuples, and function signatures are either on one line, or broken into multiple lines of one element/argument each, the formatting of extended logical expressions could be improved to emphasize the priority of 'and' over 'or' operators There is no current configuration in pyproject.toml, the default maximum line length is 88 characters. I note that setting the line length to 79 notably increases the number of line breaks needed. Note that double quotes are now preferred to single quotes.
I think that including black configuration in pyproject.toml would be a good idea, the main question is line length, 79 or 88 characters. The same question of line length can also be raised for clang-format. Lines much longer than 88 are characters are not only a problem for terminals, they are also hard to focus on if you have bad eyes, but lines longer than 79 characters also reduce the number of line breaks needed.
Thoughts?
I'd suggest: (1) let's discuss `clang-format` for C/C++ separately from `black` for Python. (2) to read https://github.com/scipy/scipy/pull/14330 and https://github.com/scipy/scipy/issues/14354 and then not even continue the discussion on `black`. A detailed proposal with an incremental formatter may have a chance here (xref `darker` and our `tools/linter.py`), a "let's just run black" one seems dead in the water given the people and opinions in the linked SciPy PR and issue from a few months ago.
"black" is under active development and has relaxed their rigid ideas on formatting. I am not advocating blindly reformatting all the files, but having something in pyproject.toml so that folks can run it on new code as a first pass and fix up places where the result is less than optimal. The main place where that might be inconvenient is the expansion of lists/tuples/signatures into vertical lists, but my impression is that one could get used to that and maybe it is an improvement. I think formatters are the future, it is just a question of when the future arrives.
Chuck _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: jeffreback@gmail.com