qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 2/2] spapr_pci: rename some struct


From: Greg Kurz
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 2/2] spapr_pci: rename some structured types
Date: Thu, 8 Nov 2018 12:48:45 +0100

On Wed, 7 Nov 2018 15:46:35 +1100
David Gibson <address@hidden> wrote:

> On Mon, Oct 15, 2018 at 12:49:53PM +1100, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 12/10/2018 20:05, Greg Kurz wrote:  
> > > According to CODING_STYLE, structured types names are expected to be
> > > in CamelCase but we have:
> > > 
> > > typedef struct spapr_pci_msi {
> > >     uint32_t first_irq;
> > >     uint32_t num;
> > > } spapr_pci_msi;
> > > 
> > > typedef struct spapr_pci_msi_mig {
> > >     uint32_t key;
> > >     spapr_pci_msi value;
> > > } spapr_pci_msi_mig;
> > > 
> > > Acronyms are often written in upper-case, but here we would en up with
> > > a lot of upper-case letters in a row (ie, sPAPRPCIMSI) which defeats the
> > > purpose of CamelCase. It even displays "RPC" which looks awkward.  
> > 
> > Yet more common than this. I vote for sPAPRPCIMSI as PCI is an acronym.
> > "pci" is small letters hurts my eyes :)  
> 
> Hrm.  So, yes, I know I kind of started it, but these various
> compromises about how to captialize things means this patch is now
> "change from non-camelcase to.. something that's also not really
> camelcase".
> 
> At which point I'm not particularly convinced it's worth the bother.
> 
> If we really want to go ahead with CamelCasing this, I think we'd need
> to start by fixing up the existing sorta-camelcase-but-not-really
> stuff to actual camelcase.  Which would mean the slightly odd reading
> "Spapr" and "Pci" and "Msi" and so forth, but it might be worth it for
> consistency.
> 

Looking at sPAPR only we already get:

$ git grep sPAPR | wc -l
1070

I understand your point but this would cause a lot of changes,
ie, a lot of noise in git blame and probably harder backports
of subsequent commits... I guess it isn't worth the pain.

Maybe we can just forget this patch and live with this minor
coding style violation. :)

Attachment: pgp7893sl8pCE.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]