clang-format: additional style options regarding systemd style

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

clang-format: additional style options regarding systemd style

Richard Smith 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 "ExceptForEachMacros" 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

ClangFormat: additional style options regarding systemd style

Richard Smith 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 "ExceptForEachMacros" 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev