[cfe-dev] clang-format: additional style options regarding systemd style

[Sebastian Jennen via cfe-dev]

Hello,

The systemd codebase is discussing the adoption of clang-format as the 
formatting tool for its code base.

See conversation here: https://github.com/systemd/systemd/pull/11308

However there are a couple of issues with clang-format for the systemd 
common style, which might be solvable by adding some new additional 
styles, which also be beneficial for other projects.


*Suggestions:*

- add a custom indent for pp directives

The general indent of the codebase is 8 spaces. But the pp indent is 
only two spaces. As the PP are fundamentally different from the C code, 
IMHO it makes sense to allow a different indent for these elements.

Additionally PP are aligned to the very left. Keeping the indent low 
helps identifying PP from C code visually, as the PP generally happens 
on the left and the C code on the right.

--> new style option "*IndentPPDirectiveWidth*" which defaults to 0. 
When zero the IndentWidth**value is used for indentation. When greater 
zero this value is used for indentation.*
*

*
*

- no space after foreach macro, with SpaceBeforeParens set to Always*
*

systemd is heavily using foreach macros throughout its code. In 
general***SpaceBeforeParens: Always***matches the style of the project. 
However the foreach macros should not have the space between foreach 
macro name and parens.

--> add new possible value "*ExceptFor**EachMacros*" to 
*SpaceBeforeParens,* which behaves as *Always,* except that  foreach 
macros should not have the space between foreach macro name and parens.**


- enum breaking behaviour*
*

when using enums with an indent width of 8 spaces and no brace wrapping 
after enum (BraceWrapping: ... AfterEnum: false)

example:

```
enum { ARG_VERSION = 0x100,
         };
```

i would have expected the following output:
```
enum {
         ARG_VERSION = 0x100,
};
```

Is this behaviour intended, or is this a bug?


Cheers, Sebastian Jennen
**

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190103/55416599/attachment.html>