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.har...@gmail.com> > wrote: > > > > >> On Sun, Nov 14, 2021 at 11:40 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote: >> >> >>> On Sun, Nov 14, 2021 at 6:14 PM Charles R Harris >>> <charlesr.har...@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-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: jeffreb...@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
