Code Formatter and Consistent Code Style

[can-leh-emmtrix]

As more people contribute to this project, I think it makes sense to add a code formatter such a clang-format in order to have a consistent code style. In my personal experience, since clang-format does the formatting automatically, it has little to no overhead for the developer compared to doing it manually with a style guide. @kraiskil Would you be open to this? Do you have a preferred clang-format configuration/style?

[kraiskil]

Agreed. The formatting is not really that coherent. In a big part also because I don´t really "see" the white space (mild dyslexia I suppose), so it is not used consistently. I think I was running the source through uncrustify at some point, but that has not been kept up.

Only thing I care about is indentation with tabs, alignment with spaces. Since sometimes it's nicer to look at 8 spaces indentation, sometimes 4 (and some people actually do prefer 2 spaces (??)).
Also using a bracing style that is not something like GNU or Withesmits (https://en.wikipedia.org/wiki/Indentation_style#C/C++_styles).
Other than those two, anything consistent is fine by me.

Among code formatters I have experience with uncrustify and clang-format only. Both are quite fragile tools in the sense that they change behaviour significantly enough between releases. This matters mostly if we decide to have CI that enforces the formatting - if so, maybe look into with something more stable than uncrustify or clang-format?
I would not want to have plain clang-format enforcing the layout on the CI. For one, GitHub updates the runners (and thereby clang-format) regularly. Would be quite annoying trying to install just the perfect and changing version of LLVM only for layouting tools.

Also, should we talk about CamelCase, dromedarCase and snake_case? It's another thing onnx2c doesn´t really handle elegantly...

[can-leh-emmtrix]

Only thing I care about is indentation with tabs, alignment with spaces. Since sometimes it's nicer to look at 8 spaces indentation, sometimes 4 (and some people actually do prefer 2 spaces (??)). Also using a bracing style that is not something like GNU or Withesmits (https://en.wikipedia.org/wiki/Indentation_style#C/C++_styles). Other than those two, anything consistent is fine by me.

Sounds fine to me.

Among code formatters I have experience with uncrustify and clang-format only. Both are quite fragile tools in the sense that they change behaviour significantly enough between releases. This matters mostly if we decide to have CI that enforces the formatting - if so, maybe look into with something more stable than uncrustify or clang-format? I would not want to have plain clang-format enforcing the layout on the CI. For one, GitHub updates the runners (and thereby clang-format) regularly. Would be quite annoying trying to install just the perfect and changing version of LLVM only for layouting tools.

For now, I would not setup CI for the code formatter. However, should it become necessary, it is quite straight forward to get specific versions of llvm via https://apt.llvm.org/. While I have not used it for clang-format before, it seems to be included in the packages as far as I can tell.

Also, should we talk about CamelCase, dromedarCase and snake_case? It's another thing onnx2c doesn´t really handle elegantly...

I think it makes sense to have a consistent style. Seems like this can also be enforced automatically though. I am personally at a point where I don't really have a strong preference between snake_case and camelCase (dromedarCase?) anymore. I like to use PascalCase for types and classes so that there won't be conflicts with variables/methods.

[can-leh-emmtrix]

I'd be happy to setup the infrastructure for this, however I think you would need to be the one who actually commits the first "Formatting Commit", as the diff will probably so large that it is essentially unreviewable. Does that work for you?

[kraiskil]

I'd be happy to setup the infrastructure for this, however I think you would need to be the one who actually commits the first "Formatting Commit", as the diff will probably so large that it is essentially unreviewable. Does that work for you?

Makes sense. I'll come up with a .clang-format, and let's discuss it before doing the One Big Push.

For now, I would not setup CI for the code formatter.

What keeps the formatting then from deteriorating over time?

There's the possibility also to format only the git diff with clang-format https://releases.llvm.org/20.1.0/tools/clang/docs/ClangFormat.html?utm_source=chatgpt.com#git-integration

[can-leh-emmtrix]

Makes sense. I'll come up with a .clang-format, and let's discuss it before doing the One Big Push.

Sounds good.

What keeps the formatting then from deteriorating over time?

Every contributor needs to invoke clang-format on their changes manually anyways. However I see the advantage of having a check for it in the CI too.

There's the possibility also to format only the git diff with clang-format https://releases.llvm.org/20.1.0/tools/clang/docs/ClangFormat.html?utm_source=chatgpt.com#git-integration

I think it makes sense to apply it to the entire project for the sake of consistency.