Message-ID: <20260117233241.5ba95b2d@pumpkin>
Date: Sat, 17 Jan 2026 23:32:41 +0000
From: David Laight <david.laight.linux@...il.com>
To: "Bird, Tim" <Tim.Bird@...y.com>
Cc: Alexey Dobriyan <adobriyan@...il.com>, Steven Rostedt
 <rostedt@...dmis.org>, Andy Shevchenko <andriy.shevchenko@...el.com>, James
 Bottomley <James.Bottomley@...senpartnership.com>,
 "ksummit@...ts.linux.dev" <ksummit@...ts.linux.dev>, Dan Williams
 <dan.j.williams@...el.com>, linux-kernel <linux-kernel@...r.kernel.org>,
 Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by
 cleanup.h

On Sat, 17 Jan 2026 16:54:43 +0000
"Bird, Tim" <Tim.Bird@...y.com> wrote:

> > -----Original Message-----
> > From: Alexey Dobriyan <adobriyan@...il.com>
> > 
> > On Fri, Jan 02, 2026 at 09:50:29AM -0500, Steven Rostedt wrote:  
> > > On Wed, 31 Dec 2025 13:17:32 +0100
> > > Andy Shevchenko <andriy.shevchenko@...el.com> wrote:
> > >  
> > > > > There was variation of this type of nonsense with headers (not only it has
> > > > > to be sorted alphabetically but by length too!)  
> > > >
> > > > By length it indeed sounds weird, but alphabetical is the natural language
> > > > order everybody learnt from the daycare / school years, so it's properly
> > > > programmed in our deep brain. Having that allows to find easily if anything one
> > > > is interested in is already being included. Also it allows to avoid dup inclusions
> > > > (was there, fixed that for real). So, it's not bad.  
> > >
> > > Actually, I like the "by length" because its aesthetically easier on the eyes.
> > >
> > > Alphabetically is fine, but either one helps in catching duplicate headers.  
> > 
> > Such rules for headers are mostly harmless -- headers are supposed to be
> > idempotent so ordering doesn't matter. But if ordering doesn't matter
> > why have a rule at all?  

> The rule is (or at least was, at one point) helpful to reduce the likelihood
> merge conflicts during patch application.  I know patch and quilt still
> don't ignore mismatched #include lines in the patch context, even
> though #include lines in C are independent of each other.  I'm not sure if git
> handles this better or not.

I prefer headers to be grouped with system headers first, then subsystem ones
and finally local ones.

Alphabetic ordering is, IMHO. silly.
If you know the name of something you cam search for it.
When you don't know the name you want it to be near something you do know.
So in a book on a cpu instruction set you want all the arithmetic
instructions next to each other not spread throughout the book.

For C variables you want the definition where you can quickly find it when
looking at the code.
Hiding it in the middle of a large block of statements doesn't help
(especially if -Wshadow isn't enabled when you might find the wrong one).
If a variable is only used in a very short block, it can be defined at the
top of the block - otherwise it really needs to be at the top of the function.
But don't initialise things that aren't semi-constant and are only used way
down the function - that just makes you have to go hunting for a value.

The location of these definitions has to be about making code easier to
quickly read.

	David

> 
> When everyone appends new #include lines at the end of the block of lines,
> there is more likelihood of a patch conflict right there.  If the #include lines
> are instead sorted in some fashion, it reduces (but obviously does not eliminate)
> the possibility of a patch conflict.
>  -- Tim
> 

Powered by blists - more mailing lists