Re: coding style

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	"Kok, Auke" <auke-jan.h.kok@intel.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Chris Friesen <cfriesen@nortel.com>,
	dave young <hidave.darkstar@gmail.com>, Willy Tarreau <w@1wt.eu>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: coding style
Date: Sat, 16 Jun 2007 08:49:55 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0706160833220.32724@fbirervta.pbzchgretzou.qr>

On Sat, 16 Jun 2007, Jan Engelhardt wrote:
> >
> >Heh. Actually, Linux maintainers have generally very consciously _avoided_ 
> >trying to "enforce" coding style issues.
> 
> Really? "it's not going to be merged unless you turn all uint32_t into
> u_int32_t" is a paraphrased variant of what I was told this month.

I suspect different maintainers are hung up on different things, so yes, 
certain things are more likely to carry red flags, and it also depends on 
the patch.

For example, if I get a patch for something that is a whole driver, I 
generally think that while I *prefer* to see it follow the kernel coding 
style, I also expect that the person who sends me the driver is the one 
who is going to maintain it in the future, and thus his personal coding 
style preferences will override any but the strongest objections.

(So if somebody sends me a FSF-style "tabs are two characters, and 
functions must be longer than 300 lines" mess, I generally would prefer to 
not take it at all, but for some really obscure driver I might not care).

In contrast, if a patch modifies code that somebody else really will end 
up touching in the future (maybe not "maintain", but maybe there is no 
single and obvious maintainer), it had better match the code around it.

So to take your particular example: For me, "uint32_t" is certainly better 
than "u_int32_t" (and there's seven times as many of the former as the 
latter in the kernel), but for code _I_ would touch, I'd actually prefer 
the Linux internal "__u32"/"u32", which have no question about what their 
user-space visibility is (ie "__u32" is *always* ok in a header file that 
is visible to user space).

But would I make it a huge issue? Not personally. So it will depend on the 
maintainer.

(Personally, I think the "small functions, no deep levels of indentation, 
and tabs are 8 characters wide" are the most important part by far. But I 
do actually end up complaining about function naming etc too).

		Linus