did some basic tests and the output looks good. Should we also integrate this into the CI so that PRs fail if they do not comply?

I thought about it, but currently it would fail for a lot of files.

well, we could enforce it for new files only?

I think formatting rules are more like an IETF SHOULD not a MUST.

So?

From my side this is an ACK. But I am quite unsure about the fact that we might fill our root directory with unused dotfiles in the future that still require maintenance. If we do not integrate this somehow in our coding conventions or automatically in the CI system, then what's the advantage of having this? Documenting the coding style can be done more generally in words and anyone who is disciplined enough and uses such a tool (uncrustify, astyler, ..) on a daily basis can come up with such a file for her/himself based on that.
Just my 0.02$...

Nevertheless, this can be a discussion for some other time. My ACK still holds and the output of some basic uncrustify runs with this config looks good. Merge at will.

But I am quite unsure about the fact that we might fill our root directory with unused dotfiles in the future that still require maintenance.

True, we should replace the astyle configuration.

If we do not integrate this somehow in our coding conventions or automatically in the CI system, then what's the advantage of having this?

We can link to this configuration to help newcomers to make their code RIOT coding style compliant.

Documenting the coding style can be done more generally in words and anyone who is disciplined enough and uses such a tool (uncrustify, astyler, ..) on a daily basis can come up with such a file for her/himself based on that.

The coding style is documented in the Wiki. I don't think that anyone who contributes more or less on a regular basis to RIOT will need and use such a tool.

And you can use such a tool for quickly "converting" external code to RIOT's style, of course.

Documenting the coding style can be done more generally in words and anyone who is disciplined enough and uses such a tool (uncrustify, astyler, ..) on a daily basis can come up with such a file for her/himself based on that.

The coding style is documented in the Wiki. I don't think that anyone who contributes more or less on a regular basis to RIOT will need and use such a tool.

We could (and I don't generally recommend this) also offer a pre-commit hook for whatever code-beautifier we use.

(I don't consider myself a "Ready for CI build"-nazi, but I still want to see a happy travis before merging)

Just tested it and noticed, that there's maybe an option missing. According to RIOT coding conventions:

Use curly braces even for one-line blocks. This improves debugging and later additions.

Adding this line:

mod_full_brace_if                        = add

makes uncrustify adding them automagically.

Maybe we should also think about including all other related options then: (add instead of ignore)

# Add or remove braces on single-line 'do' statement
mod_full_brace_do                        = ignore   # ignore/add/remove/force

# Add or remove braces on single-line 'for' statement
mod_full_brace_for                       = ignore   # ignore/add/remove/force

# Add or remove braces on single-line function definitions. (Pawn)
mod_full_brace_function                  = ignore   # ignore/add/remove/force

# Add or remove braces on single-line 'if' statement. Will not remove the braces if they contain an 'else'.
mod_full_brace_if                        = ignore   # ignore/add/remove/force

# Make all if/elseif/else statements in a chain be braced or not. Overrides mod_full_brace_if.
# If any must be braced, they are all braced.  If all can be unbraced, then the braces are removed.
mod_full_brace_if_chain                  = false    # false/true

# Don't remove braces around statements that span N newlines
mod_full_brace_nl                        = 0        # number

# Add or remove braces on single-line 'while' statement
mod_full_brace_while                     = ignore   # ignore/add/remove/force

# Add or remove braces on single-line 'using ()' statement
mod_full_brace_using                     = ignore   # ignore/add/remove/force

@cgundogan, for the first four and last two rules, you propose I would object, because our coding conventions do not allow these single-line statements. The rules I don't understand.

then it's time to hit the button. Merge at will