Style changes - tabulated function names

[dimitre]

I think we should change this style of tabulating function names and variable names out of the types. I can think of one ergonomic advantage of using only one space:
sometimes you will search in all OF code to see where is that function and you know the name and the type. You look for let's say: "void setWindowTitle" but it doesn't return anything because instead of one space you have one or more tabs.

Thoughts? @artificiel @ofTheo @2bbb @Jonathhhan

[artificiel]

your ergonomic advantage is true, and anyway the guidelines https://github.com/openframeworks/openFrameworks/wiki/oF-code-style already states that a single space shall be uses! (no attempts at aligning)

on that front has there been an attempt at a .clangformat? (and also maybe study the OF guidelines compatibility vs what Xcode does with ctri-i (muscle memory there))

[dimitre]

related PR #7353

[artificiel]

i tried running the style script and the results surprised me.... it seems it has not be ran in a while (notably some options don't work anymore). it also reveals a lot of core OF does not adhere to the style guide (most poignantly, the style guide prescribes indentation for the public: keyword but a lot of code does not and aligns it to class).

1. the style guide should be revised in light of 2023 (in a manner that translates to an automatic styler)

2. the style config should be updated to match the style. and is uncrustify still the thing?

3. the whole OF shall be reformatted in a big whitespace commit

4. the style config should be prominently presented and it's use mandatory (i've been on projects where the IDE is setup with a .clangformat at the project root and automatically runs upon save; it is initially surprising, but after a while you are happy about it).

[dimitre]

I personally dislike the identation for public:
it is not applied anywhere. this is one thing to change in my opinion

[artificiel]

i agree that it's better not to indent public: (the poignantness i referred to was not because it was not indented, but because it was not respecting the style).

but that's one thing amongst many: how to structure such a revision process? there is code history, personal prefs, etc... as mentioned above i don't mind much and happy to let others figure it out, but i need a config+tool that can apply the style. (note that we're discussing here whitespace, tabs, indent, brace position usage -- things like class and variable names are out of scope).

then adjust the tool (for this i can be of use). there are currently in OF scripts based on uncrustify so maybe some good work there, and maybe it's just a matter of adjusting the config (once the style is agreed upon).

or from scratch, clang-format is less "powerful" than uncrustify but seems simpler to configure and run, so an easy way out it to adopt one of the base clang-format styles (actual comparisons here) and refine from there. a quick look indicates the webkit style is the closest to the current OF style.

whichever tool is chosen, 3 or so "test cases" files should be elected from the source and serve as tests to validate the tool config.

but how shall this style revision be executed so the concrete work can then be performed?

[artificiel]

closed by #7655!