Re: [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding standard

[Evan Lloyd <Evan.Lloyd@arm.com>]

Hi Ard

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: 02 January 2018 15:21
> To: Evan Lloyd <Evan.Lloyd@arm.com>
> Cc: edk2-devel@lists.01.org; Matteo Carlini <Matteo.Carlini@arm.com>;
> eif.lindholm@linaro.org; nd <nd@arm.com>
> Subject: Re: [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding
> standard
> 
> On 2 January 2018 at 15:11, Evan Lloyd <Evan.Lloyd@arm.com> wrote:
> > Hi Ard.
> > One aim of these changes is to get those files we have to play with into a
> state where a beautifier like indent, astyle,  or clang-format can be used to
> help tidy our changes.  (NOTE, we do not have that fully working yet, but
> they do help.)  In a world where we have to play with several contradictory
> formatting standards (not just EDK2) then anything that can help is
> welcome.
> > Of the changes made:
> >         Fixing the include guards: is a small improvement.  (Ideally
> patchcheck should reject these.)
> >         Reducing lines to 80 columns: makes Leif (at least) happy, and aligns
> with formatter behaviour.
> >         Correcting Doxygen format comments: prevents Doxygen generating
> gibberish.
> >         Spaces before '(': Maintains consistency, and aligns with desired
> formatter behaviour.
> >
> 
> To be honest, this is an aspect I hadn't considered at all. It would be
> excellent if we could use tooling to fix our code wrt to coding style, and if
> changes such as these bring us closer to that goal, I am all for it.

 [[Evan Lloyd]] Excellent news - now you know why we were doing all those inexplicable things.  I really should have explained this more clearly before.

> 
> Would it be feasible to run that on entire packages, i.e., ArmPkg and
> ArmPlatformPkg?

 [[Evan Lloyd]]  As it stands, none of the tools is very happy with the EDK2 style, and they tend to miss meeting it in different ways.
(As an aside - one common problem is that I have found no means of coercing them to force the ");" at the end of a function call onto its own line.  Your recent CCS change to make that optional helps a lot with that.)  However, I have so far failed to get any of the above tools to do exactly what we want.  All that I can achieve is to generate a formatted view that can be compared against the original with a visual program like kdiff3 - highlighting some formatting improvements that can then be copied across, whilst the mismatches can be ignored.  This is not much, but it does help, especially with spacing and line length errors.

If you are interested, I am very happy to make those parameter files that I have available for consideration, as long as everyone understands how far from fully compliant they are, and that their limitations are manifold.  I suspect the path to a fully automated reformat will be a long and winding road.  The best bet might be to actually change one of the Open Source tools to suit us, but I certainly don't know of anyone with the leisure time available to take that on.

Regards,
Evan

> 
...
> >> > --
> >> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >> >