linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
To: Ingo Molnar <mingo@elte.hu>
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: Fri, 6 Feb 2009 11:30:05 +0000	[thread overview]
Message-ID: <200902061130.05740.tvrtko.ursulin@sophos.com> (raw)
In-Reply-To: <20090205180019.GC9233@elte.hu>

On Thursday 05 February 2009 18:00:19 Ingo Molnar wrote:
> * 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.

You also didn't say anything about variable declarations I asked about? And I can add structure definition to 
that question as well. 

> 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?

Actually test was invalidated by me looking for two typos in each block for a long long time. Therefore by 
providing interesting visual things to look at you made me skip the important bit with instructions. :)

But I personally think it is not such a big difference. And please remember that the part I originally 
commented on was different in a way that it had expressions on the right hand side. There with a huge gap 
between left and right you then break to logical association and make brain evaluate it as two separate groups 
which perhaps doesn't always makes sense.

And how could you say that not vertically aligning increases maximum line length is beyond me.

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

_You_ think it's fun to look at and you suspect it is the winner, which is basically my point. I think you are 
going to far. Either you specify the rules in CodingStyle or you don't have it as a reason to send patches for 
rework. Until then you can't say it is a policy, it can at least depend on circumstances.

> [ 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? ]

Yes I have, it looks like ordinary word wrap when replying. I don't see any other corruptions though - have 
you added that just to make it sound more dramatic together with suggesting I am not a developer?

> > 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?

No, my argument is that in this case it is a personal preference what is more 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.

While for some cases I also like vertical alignment, for the original code I think it  was borderline _at 
most_. 

> 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.

Well I don't wish to argue on this subject very much. 

I just thought it is unfair to criticise on an issue which cannot be a hard rule and in a particular example 
was not an improvement. 

Since you also agree it is not possible to describe it as a hard rule, why bother people with it?

Tvrtko

  reply	other threads:[~2009-02-06 11:30 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
2009-02-06 11:30       ` Tvrtko Ursulin [this message]
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=200902061130.05740.tvrtko.ursulin@sophos.com \
    --to=tvrtko.ursulin@sophos.com \
    --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@elte.hu \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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).