[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160228132717.GD2854@techsingularity.net>
Date: Sun, 28 Feb 2016 13:27:17 +0000
From: Mel Gorman <mgorman@...hsingularity.net>
To: Chen Gang <chengang@...ndsoft.com.cn>
Cc: Theodore Ts'o <tytso@....edu>, Jianyu Zhan <nasa4836@...il.com>,
trivial@...nel.org, Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>, rientjes@...gle.com,
LKML <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.cz>,
Johannes Weiner <hannes@...xchg.org>, vdavydov@...tuozzo.com,
Dan Williams <dan.j.williams@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Chen Gang <gang.chen.5i5j@...il.com>
Subject: Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles
On Sun, Feb 28, 2016 at 08:21:40AM +0800, Chen Gang wrote:
>
> On 2/28/16 00:53, Theodore Ts'o wrote:
> > On Sat, Feb 27, 2016 at 10:32:04PM +0800, Chen Gang wrote:
> >> I don't think so. Of cause NOT the "CODE CHURN". It is not correct to
> >> make an early decision during discussing.
> >
> > There is no discussion. If the maintainer has NAK'ed it. That's the
> > end of the dicsussion. Period. See:
> >
>
> For me, NAK also needs reasons.
>
You already got the reasons. Not only does a patch of this type interfere
with git blame which is important even in headers but I do not think the
patch actually improves the readability of the code. For example, the
comments move to the line after the defintions which to my eye at least
looks clumsy and weird.
> I guess they are related with this patch, and their NAKs' reason are: mm
> and trivial don't care about this coding style issue, is it correct?
>
No. Coding style is important but it's a guideline not a law. There are
cases where breaking it results in perfectly readable code. At least one
my my own recent patches was flagged by checkpatch as having style issues
but fixing the style was considerably harder to read so I left it. If the
definitions in that header need to change again in the future and there
are style issues then they can be fixed in the context of a functional
change instead of patching style just for the sake of it.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists