You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
clangformat all the code to be a consistent format #572
clang-format is a tool to format C/C++/... code according to a set of rules and heuristics. Like most tools, it is not perfect nor covers every single case, but it is good enough to be helpful.
clang-format can be used for several purposes:
Quickly reformat a block of code to the kernel style. Specially useful when moving code around and aligning/sorting. See [clangformatreformat](https://docs.kernel.org/dev-tools/clang-format.html#clangformatreformat).
Spot style mistakes, typos and possible improvements in files you maintain, patches you review, diffs, etc. See [clangformatreview](https://docs.kernel.org/dev-tools/clang-format.html#clangformatreview).
Help you follow the coding style rules, specially useful for those new to kernel development or working at the same time in several projects with different coding styles.
Its configuration file is .clang-format in the root of the kernel tree. The rules contained there try to approximate the most common kernel coding style. They also try to follow Documentation/process/coding-style.rst as much as possible. Since not all the kernel follows the same style, it is possible that you may want to tweak the defaults for a particular subsystem or folder. To do so, you can override the defaults by writing another .clang-format file in a subfolder.
Sounds reasonable as it should make the code easier to maintain. Do we spot style mistakes to warn, or do we reformat directly? I guess all files will be touched, so intensive testing is necessary. Would it make sense to look into unit testing first (#568)?
I am hesitant. If you continue please run a PR to a branch other than master so we can first test the changes.
Plus: Reformatting the code may make all currently open PRs void. Let's work on them first.
Otherwise I am looking forward to seeing a forced doxygen style documentation on new or changed code.
I think the first thing to do with those old PRs is to push a commit which should hopefully get them to at least build on Ubuntu, Fedora and Arch since there is now a GH Action. If they won't build, then unless the original author fixes them, then I doubt anyone else will. Even if they do build, I wouldn't know if they do what they say they are supposed to do. For example the sell option one would presumably require someone to play the game and try it out.
These days, I don't ever actually play Oolite, I just compile and launch it, make sure it works, then close it again to move on to the next dev item. This project has a shortage of volunteers willing to step forward and make contributions in more than just dev work. We need not just devs but testers. For example, when AnotherCommander asked for testers of the MSIX, it was just me that tested it.
Delaying clang-formatting makes future Obj-C code contributions more difficult as the current code uses the outdated approach of tabs instead of spaces plus there are random tabs all over the place. It makes editing trickier than it need be.
We need something more solid than just human testers which are too few and likely to not always go through the same test procedure. Hence I raise the need for unit tests which will make code development a lot easier.
Let's have a good handling of the currently open PRs, then we continue on reformatting the code.
@oocube Since this is blocked on the open PRs, please go ahead and get the existing old PRs to build so we can see where they are (I can see your force pushed some of them before so I guess it's the same process).
PRs have been merged or closed. There is one left but it is something that can wait as it'll require a lot of testing and in any case requires implementing differently #738.
#745 (merged) and #748 (awaiting approval) bring the code into a form where clangformat will work smoothly.
Activity
oocube commentedon Apr 3, 2026
From https://docs.kernel.org/dev-tools/clang-format.html:
Sounds reasonable as it should make the code easier to maintain. Do we spot style mistakes to warn, or do we reformat directly? I guess all files will be touched, so intensive testing is necessary. Would it make sense to look into unit testing first (#568)?
mcarans commentedon Apr 3, 2026
All code would be reformatted as a one off then a GH Action workflow would ensure that code cannot be checked in that isn't formatted correctly.
oocube commentedon Apr 3, 2026
I am hesitant. If you continue please run a PR to a branch other than master so we can first test the changes.
Plus: Reformatting the code may make all currently open PRs void. Let's work on them first.
Otherwise I am looking forward to seeing a forced doxygen style documentation on new or changed code.
mcarans commentedon Apr 4, 2026
I think the first thing to do with those old PRs is to push a commit which should hopefully get them to at least build on Ubuntu, Fedora and Arch since there is now a GH Action. If they won't build, then unless the original author fixes them, then I doubt anyone else will. Even if they do build, I wouldn't know if they do what they say they are supposed to do. For example the sell option one would presumably require someone to play the game and try it out.
These days, I don't ever actually play Oolite, I just compile and launch it, make sure it works, then close it again to move on to the next dev item. This project has a shortage of volunteers willing to step forward and make contributions in more than just dev work. We need not just devs but testers. For example, when AnotherCommander asked for testers of the MSIX, it was just me that tested it.
Delaying clang-formatting makes future Obj-C code contributions more difficult as the current code uses the outdated approach of tabs instead of spaces plus there are random tabs all over the place. It makes editing trickier than it need be.
oocube commentedon Apr 4, 2026
I could not agree more.
We need something more solid than just human testers which are too few and likely to not always go through the same test procedure. Hence I raise the need for unit tests which will make code development a lot easier.
Let's have a good handling of the currently open PRs, then we continue on reformatting the code.
mcarans commentedon Apr 4, 2026
@oocube Since this is blocked on the open PRs, please go ahead and get the existing old PRs to build so we can see where they are (I can see your force pushed some of them before so I guess it's the same process).
mcarans commentedon Sep 21, 2026
PRs have been merged or closed. There is one left but it is something that can wait as it'll require a lot of testing and in any case requires implementing differently #738.
#745 (merged) and #748 (awaiting approval) bring the code into a form where clangformat will work smoothly.