I've spoken to @djasper about this style and have just started to work on
adding a new option to support it.
The closest I was able to get was to set:
*AlignAfterOpenBracket: false *
(1) Fit everything in 1 line.
void someReallyLongFunction(int firstParameter, int secondParameter)
(2) Fit everything in next line
int firstParameter, int secondParameter, int thirdParameter)
firstParameter, secondParameter, thirdParameter);
(3) Everything on its own line
void someReallyLongFunction(int firstParameter,
Currently, I live with this configuration and wrap the first
parameter/argument manually. (Not ideal, but still beats formatting all of
*NOTE*: If you're looking to skip (2), you can also set *AllowAllParametersOfDeclarationOnNextLine:
false*. A caveat here is that this only applies for parameters and *not* for
arguments. @djasper: Since we have *BinPackParameters* and
*BinPackArguments* separated now, perhaps we could also introduce
*AllowAllArgumentsOnNextLine* option to control this?
I'd think that we should rather get rid of
AllowAllParametersOfDeclarationOnNextLine and instead turn
BinPackParameters/BinPackArguments into an enum.
I really like a refactoring and version system friendly code style
What I means is that we don't want to align parameter/arguments based on
the name of the function. So when the parameter/arguments don't fit on one
line we want each of them on their own line but we first want have a break
before the first parameter.
I tried already a lot of option and played with the Penalties but had no
Any idea if this is possible with the current set of options?
It is not and I'd be very hesitant to support it based on your reasoning.
Refactoring and version system friendliness are concerns when writing code.
clang-format's explicit goal is to make code readable. Code in general is
read way more often than it is written and thus optimizing for writeability
isn't a good idea in general.
Generally, the bar for options to make it into clang-format are that either
they are trivial which this isn't or they are used in large (ideally
open-source) projects and have a publicly available style guide where the
precise rules are written down. This is a trade-off, but in general, we'd
much rather have clang-format support a subset of thinkable styles really
well instead of having it support every little style nuance that somebody
might like. Now, if there are large projects and accessible style guides,
this trade-off changes somewhat as the value clang-format might give to
people working on such projects outweigh the additional cost.
I think clang-format already has too many style options (as we have been
too lenient when apply the bar mentioned above) and would much rather kill
some of them instead of introducing even more.