From: Greg Kurz <groug@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: "Alexey Kardashevskiy" <aik@ozlabs.ru>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] spapr_pci: rename some structured types
Date: Thu, 8 Nov 2018 12:48:45 +0100 [thread overview]
Message-ID: <20181108124845.25053d19@bahia.lan> (raw)
In-Reply-To: <20181107044635.GE5575@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
On Wed, 7 Nov 2018 15:46:35 +1100
David Gibson <david@gibson.dropbear.id.au> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-11-08 11:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 9:04 [Qemu-devel] [PATCH v2 0/2] spapr_pci: coding style fixes Greg Kurz
2018-10-12 9:05 ` [Qemu-devel] [PATCH v2 1/2] spapr_pci: convert g_malloc() to g_new() Greg Kurz
2018-10-12 9:43 ` Philippe Mathieu-Daudé
2018-10-15 1:04 ` David Gibson
2018-10-12 9:05 ` [Qemu-devel] [PATCH v2 2/2] spapr_pci: rename some structured types Greg Kurz
2018-10-15 1:49 ` Alexey Kardashevskiy
2018-11-07 4:46 ` David Gibson
2018-11-08 11:48 ` Greg Kurz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181108124845.25053d19@bahia.lan \
--to=groug@kaod.org \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=f4bug@amsat.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).