[cfe-dev] clang-format Style for RTEMS

[Oleg Smolsky via cfe-dev]

On 2018-12-15 00:53, Mikail Yayla via cfe-dev wrote:
> Hello,
>
> for the rtems (https://www.rtems.org/) source code we are trying to 
> describe the rtems formatting style 
> (https://devel.rtems.org/wiki/Developer/Coding/Conventions) using 
> clang-format.
> To see whether it can be done, we used ratemonperiod.c as an example 
> and tried to set up a .clang-config file to describe the formatting.
>
> In the mail I added the .clang configuration file and a 
> ratemonperiodWKCustom_Commented.c, which is ratemonperiodOriginal.c 
> with the configuration in .clang-config applied.
>
> There are several problems in ratemonperiodWKCustom_Commented.c using 
> clang-format.
> Our questions are whether these points can be resolved using different 
> configurations.
> If they are not available with different configurations, we would like 
> to ask you how much effort would be needed to implement the 
> functionality which seems missing in clang-format:
>
> The problems/needed functionality in ratemonperiodWKCustom_Commented.c:
>
> 1. In line 30-32, we can see that the "*" of the pointers are not 
> aligned to the right. This is not supported yet it clang-format (see 
> https://stackoverflow.com/questions/38392889/clang-format-align-asterisk-of-pointer-declaration-with-variable-name).
>
Just set "PointerAlignment: Right". It works, I use it daily. However, 
you will not get whitespace to align the parameters into columns. AFAIR 
there is no such option.


> 2. In line 32, the ")" at the end of the parameter list needs to be in 
> a new row, but this doesn't seem to be supported in clang-format.
>
> 4. In line 44: If the function call is split into multiple rows, the 
> ");" should always be in a new row.
>
I don't believe there is an option to do that.

Generally, the tool supports LLVM/Google/WebKit/Mozilla styles fully and 
there is a limited set of common/known tweaks that further customize the 
behavior. One can dream up any number of rules that pertain to 
whitespace in different parts of the C++ syntax, but it would be an 
uphill battle for you to get such changes into the code.

Or looking at it from the opposite direction - every one of us has 
preferences that pertain to whitespace, yet the tool has a finite number 
of options. From my experience it is much better to sacrifice a few 
minor points and get automatic formatting across the entire team than 
spend time writing/fixing/reviewing whitespace.

Oleg.