Skip to content
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

ENH: Add clang-format file #19754

Merged
merged 1 commit into from Sep 3, 2021
Merged

Conversation

charris
Copy link
Member

@charris charris commented Aug 25, 2021

Clang-format can be used to reformat C/C++ code for codestyle fixups. The .clang-format file here implements the NumPy codestyle document as much as possible. The initial version here is taken from @pganssle's file at
https://gist.github.com/pganssle/0e3a5f828b4d07d79447f6ced8e7e4db, he is listed as co-author.

I've included a formatted version of convert.c for before/after comparison, it can be removed before merging.

Closes #19363.

@seberg
Copy link
Member

seberg commented Aug 25, 2021

Nice, browsing the options a bit, would ContinuationIndentWidth: 8 be closer to current usage?

@charris
Copy link
Member Author

charris commented Aug 25, 2021

Already uncovered some errors by sorting the includes 👎

would ContinuationIndentWidth: 8 be closer to current usage?

Yes. We might also want to change the line length for C++ at some point, although I would prefer not to. There are a few other changes we might want to make.

@seberg
Copy link
Member

seberg commented Aug 25, 2021

Already uncovered some errors by sorting the includes -1

Our includes are terrible :( (and I am happy to admit, that I am not making it better). There is some maze where include order matters due to INTERNAL BUILD and maybe other things. Or where files just work because they include a header that incidentally includes something they need...

It would be extremely nice to clean it up a bit, I feel I am missing some best practices/intuition, though.

@@ -368,8 +369,7 @@ PyArray_FillWithScalar(PyArrayObject *arr, PyObject *obj)
* the element in that array instead.
*/
if (PyArray_DESCR(arr)->type_num == NPY_OBJECT &&
!(PyArray_Check(obj) &&
PyArray_NDIM((PyArrayObject *)obj) == 0)) {
!(PyArray_Check(obj) && PyArray_NDIM((PyArrayObject *)obj) == 0)) {
value = (char *)&obj;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need an indent of the continued condition expression. I think the BSD style has that.

@charris
Copy link
Member Author

charris commented Aug 25, 2021

Made a couple of other changes. Waiting for criticisms :)

|| (PyArray_IS_F_CONTIGUOUS(self) && (order == NPY_FORTRANORDER))) {
ret = PyBytes_FromStringAndSize(PyArray_DATA(self), (Py_ssize_t) numbytes);
if ((PyArray_IS_C_CONTIGUOUS(self) && (order == NPY_CORDER)) ||
(PyArray_IS_F_CONTIGUOUS(self) && (order == NPY_FORTRANORDER))) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any option to force greater indentation in the if statement condition continuation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, maybe AlignAfterOpenBracket: DontAlign, although likely it will have its own issues? Or does that not affect conditionals?

@charris charris force-pushed the add-clang-format-file branch 2 times, most recently from 4e8286e to 4adb838 Compare August 26, 2021 00:31
@charris
Copy link
Member Author

charris commented Aug 26, 2021

Our includes are terrible

The google style sorts the headers in groups by level, so it doesn't sort them all together. It also looks like #define breaks them into groups, but I am not sure of that.

One potential problem is the clang-format version. There are features in version 12 that would be useful. Hmm, looks like it is available in focal (updates) and I have it in fedora 34, so maybe we can go that way. What I'd like to do is forbid one line enums, but we don't have that many of them and that choice is probably arguable.

@charris
Copy link
Member Author

charris commented Aug 26, 2021

I feel I am missing some best practices/intuition, though.

Some code styles require that header files be stand alone, that is, that they include everything needed to compile.

@charris
Copy link
Member Author

charris commented Aug 26, 2021

clang-format currently puts spaces around * and / even though that isn't required by the google style guide.

@charris
Copy link
Member Author

charris commented Aug 26, 2021

I think this is as good as it can get for now. Using it requires clang-format version 12. Should the three reformatted files be included?

@charris charris changed the title WIP, ENH: Add clang-format file ENH: Add clang-format file Aug 26, 2021
charris added a commit to charris/numpy that referenced this pull request Aug 26, 2021
@charris charris removed the 25 - WIP label Aug 27, 2021
@@ -1,6 +1,8 @@
#ifndef _NPY_PRIVATE__ARRAY_ASSIGN_H_
#define _NPY_PRIVATE__ARRAY_ASSIGN_H_

#include "numpy/arrayobject.h"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the extra include?

Copy link
Member Author

@charris charris Sep 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the extra include?

It was to make the include order safe. However, it turns out that .clang-format provides a mechanism for automatically grouping and ordering includes, so I am going to formalize our include ordering.

EDIT: Once I figure out what it is :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell this include is not moved, it is new to the file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this include is not moved

True, it happened to sort after the needed numpy/* includes, so didn't cause a problem, but that was an accident. I'm going the put the numpy/* includes into their own group so they always come first and then we won't need to worry.

@mattip
Copy link
Member

mattip commented Sep 1, 2021

Should the three reformatted files be included?

Could we do like python: add a linter and have it report errors only on code that is part of the PR (without taking a stand on the files you have already processed)?

@charris
Copy link
Member Author

charris commented Sep 1, 2021

Could we do like python

Maybe, there are several integrations that I haven't explored yet. I do know that it can be run on line ranges.

charris added a commit to charris/numpy that referenced this pull request Sep 1, 2021
charris added a commit to charris/numpy that referenced this pull request Sep 1, 2021
@charris
Copy link
Member Author

charris commented Sep 1, 2021

add a linter and have it report errors only on code that is part of the PR

There are several actions available in the github Marketplace, I haven't looked closely at them. Some automatically reformat files on merge, others look to reformat differences on pushes to PRs. Not sure what would be best. If I could, I'd reformat all the C files first, that would also allow working out any kinks found in the process. But I know that there is resistance to massive reformatting at the point, although I did it in the past. The template files are also likely to pose difficulties, although I haven't tried yet. On the plus side, most of the changes seem to involve indentation and spacing around operators, and we are already pretty good on that score. Note that at this time all the binary operators get spaces, including * and /, which is annoying but can be lived with.

charris added a commit to charris/numpy that referenced this pull request Sep 1, 2021
@charris charris removed the 25 - WIP label Sep 2, 2021
charris added a commit to charris/numpy that referenced this pull request Sep 3, 2021
@charris
Copy link
Member Author

charris commented Sep 3, 2021

Close/reopen

@charris charris closed this Sep 3, 2021
@charris charris reopened this Sep 3, 2021
charris added a commit to charris/numpy that referenced this pull request Sep 3, 2021
charris added a commit to charris/numpy that referenced this pull request Sep 3, 2021
@charris charris force-pushed the add-clang-format-file branch 2 times, most recently from b4162ae to 082646f Compare September 3, 2021 15:38
Clang-format can be used to reformat C/C++ code for codestyle
fixups. The `.clang-format` file here implements the
NumPy codestyle document as much as possible.

Co-authored-by: Paul Ganssle <paul@ganssle.io>
@charris
Copy link
Member Author

charris commented Sep 3, 2021

I've removed the example so that future changes after reformatting can go into separate PRs.

@charris charris merged commit 644c55e into numpy:main Sep 3, 2021
@charris charris deleted the add-clang-format-file branch September 3, 2021 18:26
@pganssle
Copy link
Contributor

pganssle commented Sep 3, 2021

FYI I don't recall how I came up with that original file, but presumably I did it myself since I felt comfortable releasing it the first time someone asked, so if that licensing question is still active you have my blessing (not sure if it even qualifies for copyright anyway).

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

Successfully merging this pull request may close these issues.

Add a .clang-format file for pretty printing C code
4 participants