Re: [edk2-CCodingStandardsSpecification PATCH 2/2] Source Files / Spacing / Multi-line func. calls: allow condensed arguments

[Laszlo Ersek <lersek@redhat.com>]

On 08/12/17 12:13, Leif Lindholm wrote:
> On Fri, Aug 11, 2017 at 01:45:12PM -0700, Jordan Justen wrote:
>>> +Use this line breaking style especially if it saves a format string or complex
>>> +argument from being split, or when commenting on individual arguments.
>>> +
>>> +##### 5.2.2.4.2 The "condensed arguments" style
>>> +
>>> +For most function calls and function-like macro invocations, the "one argument
>>> +per line" style uses up valuable vertical space without utilizing readily
>>> +available horizontal space. Such statements are permitted to condense the
>>> +arguments and the closing parenthesis (or parentheses), up to the allowed line
>>> +length. The indentation requirements are identical to those of the "one
>>> +argument per line" style.
>>> +
>>> +```c
>>> +CopyMem (Destination, Source, SIZE_4KB);
>>> +
>>> +Status = gBS->AllocatePool (EfiBootServicesData, sizeof (DRIVER_NAME_INSTANCE),
>>> +                &PrivateData);
>>
>> I prefer that we just have one style, and just drop the requirement
>> that multiline param lists can only have one arg per line. I think it
>> is good to have the first param start on the next line in this case.
>>
>>   Status = gBS->AllocatePool (
>>                   EfiBootServicesData, sizeof (DRIVER_NAME_INSTANCE),
>>                   &PrivateData);
> 
> I like this one better than Laszlo's proposal, since it keeps the
> start of each line of parameters in the same column.
> 
>> This compacts things somewhat, but still keeps the parameter list
>> aligned horizontally on subsequent lines.
>>
>> Regarding the closing parens being on a separate line, I think we
>> should also remove that as a requirement.
> 
> I would also support that change.
> 
>> I think you might want to break out the multiple params per line and
>> closing parens change out to allow for separate discussion.
> 
> That would make sense.
> 
> Laszlo - many thanks to starting this discussion!

Thanks all for the feedback. Before I attempt to post version 2, I'd
like to see the "preference" wording sorted out (raised by Mike and
Jordan). I.e., whether the new style should be merely tolerated (but
still frowned upon) or if it should be a first class citizen.

(Stating the obvious,) if the new style were accepted into the CCS,
personally I would switch to it for all new code written by me (even if
the code were for MdePkg or MdeModulePkg), independently of the
preference assigned to the new style.

I would not require OvmfPkg / ArmVirtPkg contributors to follow my
preference -- NB I've been enforcing the one style we now have in the
CCS, for the packages I co-maintain, in spite of my dislike for that
style -- but I might suggest the alternative style to others if I
perceived the vertical space consumption very disturbing.

Thanks!
Laszlo