Re: Xen Coding style and clang-format

[George Dunlap <George.Dunlap@citrix.com>]

> On Oct 1, 2020, at 10:06 AM, Anastasiia Lukianenko <Anastasiia_Lukianenko@epam.com> wrote:
> 
> Hi,
> 
> On Wed, 2020-09-30 at 10:24 +0000, George Dunlap wrote:
>>> On Sep 30, 2020, at 10:57 AM, Jan Beulich <jbeulich@suse.com>
>>> wrote:
>>> 
>>> On 30.09.2020 11:18, Anastasiia Lukianenko wrote:
>>>> I would like to know your opinion on the following coding style
>>>> cases.
>>>> Which option do you think is correct?
>>>> 1) Function prototype when the string length is longer than the
>>>> allowed
>>>> one
>>>> -static int __init
>>>> -acpi_parse_gic_cpu_interface(struct acpi_subtable_header
>>>> *header,
>>>> -                             const unsigned long end)
>>>> +static int __init acpi_parse_gic_cpu_interface(
>>>> +    struct acpi_subtable_header *header, const unsigned long
>>>> end)
>>> 
>>> Both variants are deemed valid style, I think (same also goes for
>>> function calls with this same problem). In fact you mix two
>>> different style aspects together (placement of parameter
>>> declarations and placement of return type etc) - for each
>>> individually both forms are deemed acceptable, I think.
>> 
>> If we’re going to have a tool go through and report (correct?) all
>> these coding style things, it’s an opportunity to think if we want to
>> add new coding style requirements (or change existing requirements).
>> 
> 
> I am ready to discuss new requirements and implement them in rules of
> the Xen Coding style checker.

Thank you. :-)  But what I meant was: Right now we don’t require one approach or the other for this specific instance.  Do we want to choose one?

I think in this case it makes sense to do the easiest thing.  If it’s easy to make the current tool accept both styles, let’s just do that for now.  If the tool currently forces you to choose one of the two styles, let’s choose one.

 -George