From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Jacopo Mondi <jacopo@jmondi.org>, Sean Young <sean@mess.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] media: Document coding style requirements
Date: Thu, 21 Oct 2021 17:17:59 +0100 [thread overview]
Message-ID: <20211021171759.1857aeef@sal.lan> (raw)
In-Reply-To: <YXGHw6FPfPddXMj2@pendragon.ideasonboard.com>
Em Thu, 21 Oct 2021 18:31:15 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> > > > + - one structure/enum member declaration per line;
> > > > + - one variable declaration per line;
> > >
> > > Hmm, I don't mind something like: int i, j;
> >
> > I don't mind having things like:
> >
> > struct *dev, *parent_dev;
> >
> > or even:
> >
> > struct *parent_dev, *dev = pdev->dev;
> >
> > What it is really ugly is having multiple initialized vars at the
> > same declaration, like:
> >
> > struct *parent_dev = pdev->dev.parent, *dev = pdev->dev;
> >
> > or, even worse:
> >
> > struct *dev = pdev->dev, *parent_dev = dev.parent;
>
> Cording style is one of the main candidate areas for bikeshedding. The
> first question that we should answer, I believe, is whether or not we
> want to define a more precise coding style for the subsystem to achieve
> higher uniformity, and how much latitude we want to give to developers.
I would prefer to give more freedom to developers, provided that the
code is easy to read/maintain. Having to request multiple reviews just
due coding style nitpicking seems to be a waste of time for everyone ;-)
> For instance, I don't mind
>
> unsigned int i, j;
>
> too much, but I would scream in horror at
>
> char *name = dev_name, c = '\0';
Yeah, multiple vars being declared and assigned at the same line is something
that should be avoided. See, even single letter vars with obvious assigns,
like:
int i = 0, j = 1;
are less readable than:
int i = 0;
int j = 1;
> (I'm sad C even allows declaring a char pointer and a char variable on
> the same line like this). There are lots of cases between those two
> extremes that are more or less good (or bad) depending on who you ask,
> so we won't be able to come up with a precise set of rules that draw a
> line somewhere in the middle. What we could do is err more on the side
> of strictness, for instance with
>
> - One variable declaration per line. As an exception, grouping multiple
> single-letter counter variables on a single line is allowed.
>
> (or even allowing no exception). This is probably stricter than it needs
> to be, and in some cases it will result in a few more lines of code, but
> if it brings increased readability and maintainability through
> uniformity it's something we could consider.
I don't think that things like:
int ret, i, j;
are less readable/maintainable than:
int ret;
int i;
int j;
Between the above, I would opt to the shorter format, when there's no
variable initialization (no matter if the vars have single or multiple
chars).
On the other hand, I won't be nacking/rejecting a patch if it uses
the longer format, as, for me, both are equivalent, in terms of
maintenance and readability.
So, for me, the rule should be just:
- don't declare and initialize multiple variables at the same line.
>
> The same reasoning can apply to C++ comments, we can decide to allow
> them or not, but the more flexibility there will be in the rules, the
> less uniformity we'll have, which I personally believe hinders
> readability.
Yeah, agreed.
Regards,
Mauro
next prev parent reply other threads:[~2021-10-21 16:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 9:20 [PATCH] media: Document coding style requirements Jacopo Mondi
2021-10-19 9:24 ` Sakari Ailus
2021-10-19 10:01 ` Jacopo Mondi
2021-10-21 15:45 ` Laurent Pinchart
2021-10-21 14:00 ` Hans Verkuil
2021-10-21 14:10 ` Hans Verkuil
2021-10-21 14:58 ` Mauro Carvalho Chehab
2021-10-21 14:55 ` Mauro Carvalho Chehab
2021-10-21 15:31 ` Laurent Pinchart
2021-10-21 16:17 ` Mauro Carvalho Chehab [this message]
2021-10-21 18:20 ` Jacopo Mondi
2021-10-22 5:24 ` Laurent Pinchart
2021-10-21 18:09 ` Jacopo Mondi
2021-10-21 15:14 ` Laurent Pinchart
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=20211021171759.1857aeef@sal.lan \
--to=mchehab@kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sean@mess.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.