linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
Cc: Ed Swierk <eswierk@aristanetworks.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] Detect mmconfig on nVidia MCP55
Date: Thu, 5 Feb 2009 19:00:19 +0100	[thread overview]
Message-ID: <20090205180019.GC9233@elte.hu> (raw)
In-Reply-To: <200902051705.33410.tvrtko.ursulin@sophos.com>


* Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote:

> On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote:
> > 2) Please use vertical spaces when initializing structure fields. Instead
> > of the messy looking (and over-long-line generating) construct of:
> >
> >         pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25;
> >         pci_mmcfg_config[0].pci_segment = 0;
> >         pci_mmcfg_config[0].start_bus_number = 0;
> >         pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) &
> > 3))) - 1; pci_mmcfg_config_num = 1;
> >
> >    You will get something like:
> >
> >         config->address                 = (extcfg & 0x00007fff) << 25;
> >         config->pci_segment             = 0;
> >         config->start_bus_number        = 0;
> >         config->end_bus_number          = (1 << (8 - ((extcfg >> 28) &
> > 3)));
> >
> >         pci_mmcfg_config = config;
> >         pci_mmcfg_config_num = 1;
> >
> >    Which makes it more structured, more reviewable - and more pleasant to
> >    look at as well.

It is arch/x86/ and scheduler / etc. policy for new code - and we follow 
that principle when we clean up code as well.

Same goes for static structure initializers. We do:

 static const struct file_operations perf_fops = {
	.release		= perf_release,
	.read			= perf_read,
	.poll			= terf_poll,
	.unlocked_ioctl		= perf_ioctl,
	.compat_ioctl		= perf_ioctl,
 };

And not:

 static const struct file_operations perf_fops = {
	.release = perf_release,
	.read = perf_read,
	.poll = perf_poll,
	.unlocked_ioctl	= perf_ioctl,
	.compat_ioctl = pert_ioctl,
 };

Beyond the prettiness and fun to look at factor, there are other advantages 
of vertical spaces as well:

Trivia: you play the role of the code reviewer. I have hidden two typos in 
the initializers above, one in each initializer block. The typos are of the 
same type but are in difference places so both need to be found 
individually.

Try to find the typos, and record the number of seconds it took for you to 
find them. Which typo took less time to find?

I'd suspect that for most people block#1 is the winner.

[ Note, you have a look at it as real source code with fixed width fonts and 
  you'll see the difference. You seem to be using KMail or so: there's weird 
  line wraps and other corruption of the code in your quote above - have you 
  really looked at the real code how it looks like to developers? ]

> I find it a matter of personal preference whether it is more pleasant to 
> look at and whether it is more or less readable.

Is your argument that to you it is less pleasant to look at?

Differences in taste is OK in borderline issues, but i think this one is far 
from being borderline, it's a basic typographic and aesthetic principle.

I'm not sure vertical spaces can be properly described via more rigid 
CodingStyle rules - for example vertical spaces look ugly if there's just 
two field initializations for example - but in the above case they are 
clearly the right thing to do.

	Ingo

  reply	other threads:[~2009-02-05 18:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-04 16:39 [PATCH] Detect mmconfig on nVidia MCP55 Ed Swierk
2009-02-04 17:04 ` Ingo Molnar
2009-02-05 17:05   ` Tvrtko Ursulin
2009-02-05 18:00     ` Ingo Molnar [this message]
2009-02-06 11:30       ` Tvrtko Ursulin
2009-02-06 15:42         ` Ingo Molnar
2009-02-06 16:10           ` Tvrtko Ursulin
2009-02-09 19:26   ` Ed Swierk
2009-02-09 19:42     ` Yinghai Lu
2009-02-04 17:07 ` Loic Prylli
2009-02-04 17:37   ` Ed Swierk
2009-02-04 20:00     ` Yinghai Lu
2009-02-04 20:12 ` Yinghai Lu
2009-02-04 21:25   ` Ingo Molnar
2009-02-04 23:10     ` Yinghai Lu
2009-02-10  1:59       ` [PATCH] x86/pci: host mmconfig detect clean up v3 Yinghai Lu
2009-02-10  2:00         ` Subject: [PATCH] x86/pci: Detect mmconfig on nVidia MCP55 -v2 Yinghai Lu
2009-02-10 22:57           ` Ed Swierk
2009-02-11  5:05             ` Yinghai Lu
2009-02-11 22:00               ` Ed Swierk
2009-02-12  5:03           ` Ed Swierk
2009-02-12  5:02         ` [PATCH] x86/pci: host mmconfig detect clean up v3 Ed Swierk
2009-02-05  2:24     ` [PATCH] x86/pci: host mmconfig detect clean up v2 Yinghai Lu
2009-02-05 18:15       ` Ingo Molnar
2009-02-05 18:31         ` Yinghai Lu
2009-02-05 22:04           ` Ed Swierk
2009-02-05 22:36             ` Yinghai Lu

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=20090205180019.GC9233@elte.hu \
    --to=mingo@elte.hu \
    --cc=eswierk@aristanetworks.com \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tvrtko.ursulin@sophos.com \
    /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).