[cfe-dev] always break if params don't fit

[Daniel Jasper]

On Wed, May 13, 2015 at 9:10 AM, Michael Park <mcypark at gmail.com> wrote:

> Hi Tim,
>
> 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 *
>
>
> which produces:
>
> (1) Fit everything in 1 line.
>
> void someReallyLongFunction(int firstParameter, int secondParameter)
>> {
>>   someReallyLongObject.someReallyLongFunction(firstParameter,
>> secondParameter);
>> }
>>
>
> (2) Fit everything in next line
>
> void someReallyLongFunction(
>>     int firstParameter, int secondParameter, int thirdParameter)
>> {
>>   someReallyLongObject.someReallyLongFunction(
>>       firstParameter, secondParameter, thirdParameter);
>> }
>>
>
> (3) Everything on its own line
>
>
>> void someReallyLongFunction(int firstParameter,
>>     int secondParameter,
>>     int thirdParameter,
>>     int fourthParameter,
>>     int fifthParameter)
>> {
>>   someReallyLongObject.someReallyLongFunction(firstParameter,
>>       secondParameter,
>>       thirdParameter,
>>       fourthParameter,
>>       fifthParameter);
>> }
>
>
> Currently, I live with this configuration and wrap the first
> parameter/argument manually. (Not ideal, but still beats formatting all of
> it manually!)
>
> *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.

MPark.
>
> On 12 May 2015 at 07:28, Tim W <timpie.w at gmail.com> wrote:
>
>> 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.
>>
>>     //example
>>
>>     void fooWithAVeryLongParamList(
>>         int firstParameter,
>>         int secondParameter
>>         int lastParameter)
>>     {
>>         object.alsoThisDoenstFitSoIBreakImmidiatly(
>>             firstParameter,
>>             secondParameter,
>>             lastParameter);
>>     }
>>
>>
>> I tried already a lot of option and played with the Penalties but had no
>> luck.
>>
>> 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.

Cheers,
Daniel


>> Kind regards,
>> Tim
>>
>>
>> --
>> An Apple a day keeps Windows away
>>
>> ACCU - http://www.accu.org - Professionalism in Programming.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150513/3da7416f/attachment.html>