All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <torvalds@linux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Joe Perches <joe@perches.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"apw@canonical.com" <apw@canonical.com>,
	Christoph Lameter <cl@linux.com>,
	Daniel Micay <danielmicay@gmail.com>,
	Dennis Zhou <dennis@kernel.org>,
	"dwaipayanray1@gmail.com" <dwaipayanray1@gmail.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Linux-MM <linux-mm@kvack.org>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	"mm-commits@vger.kernel.org" <mm-commits@vger.kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: RE: function prototype element ordering
Date: Mon, 27 Sep 2021 08:21:24 +0000	[thread overview]
Message-ID: <6a84e8b3fa07483092ae79aeded81797@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHk-=wjoLAYG446ZNHfg=GhjSY6nFmuB_wA8fYd5iLBNXjo9Bw@mail.gmail.com>

From: Linus Torvalds
> Sent: 26 September 2021 22:04
> 
> On Sat, Sep 25, 2021 at 12:40 PM David Laight <David.Laight@aculab.com> wrote:
> >
> > If the function name starts at the beginning of a line it is
> > much easier to grep for the definition.
> 
> That has always been a completely bogus argument. I grep to look up
> the type as often as I grep for the function definition, plus it's not
> at all unlikely that the "function" is actually a macro wrapper, so
> grepping for the beginning of line is just completely wrong.
> 
> It's completely wrong for another reason too: it assumes a style of
> programming that has never actually been all that common. It's a very
> specific pattern to very specific projects, and anybody who learnt
> that pattern for their project is going to be completely lost anywhere
> else. So don't do it. It's just a bad idea.
> 
> So a broken "easier to grep for" is not an excuse for "make the code
> harder to read" particularly when it just makes another type of
> grepping harder, and it's not actually nearly universal enough to
> actually be a useful pattern in the first place.
> 
> It's not only never been the pattern in the kernel, but it's generally
> not been the pattern anywhere else either. It's literally one of the
> broken GNU coding standards - and the fact that almost every other
> part of the GNU coding standards were wrong (indentation, placement of
> braces, you name it) should give you a hint about how good _that_ one
> was.
> 
> Here's an exercise for you: go search for C coding examples on the
> web, and see how many of them do
> 
>     int main(int argc, char **argv)
> 
> vs how many of them do
> 
>     int
>     main(int argc, char **argv)

It makes a bigger difference with:

struct frobulate *find_frobulate(args)
which is going to need a line break somewhere.
Especially with the (strange) rule about aligning the continued
arguments with the (.

But I didn't expect such a long response :-)

I'm sure the netBSD tree (mostly) puts the function name in column 1.
But after that uses the K&R location for {} (as does Linux).

It true that a lot of 'coding standards' are horrid.
Putting '} else {' on one line is important when reading code.
Especially if the '}' would be at the bottom of the screen,
or worse still turning the page on a fan-fold paper listing to find
a floating 'else' = with no idea which 'if' it goes with.

The modern example of why { and } shouldn't be on their own lines is:
		...
	}
	while (...........................
	{
		...
Is that a loop bottom followed by a code block or
a conditional followed by a loop?

But none of this is related to the location of attributes unless
you need to split long lines and put the attribute before the
function name where you may need.

static struct frobulate *
__inline ....
find_frobulate(....)

Especially if you need #if around the attributes.

	David


	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2021-09-27  8:21 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  3:09 incoming Andrew Morton
2021-09-10  3:10 ` [patch 1/9] mm: move kvmalloc-related functions to slab.h Andrew Morton
2021-09-10  3:10 ` [patch 2/9] rapidio: avoid bogus __alloc_size warning Andrew Morton
2021-09-10  3:10 ` [patch 3/9] Compiler Attributes: add __alloc_size() for better bounds checking Andrew Morton
2021-09-10  3:10 ` [patch 4/9] checkpatch: add __alloc_size() to known $Attribute Andrew Morton
2021-09-10  3:10 ` [patch 5/9] slab: clean up function declarations Andrew Morton
2021-09-10  3:10 ` [patch 6/9] slab: add __alloc_size attributes for better bounds checking Andrew Morton
2021-09-10  3:10 ` [patch 7/9] mm/page_alloc: " Andrew Morton
2021-09-10  3:10 ` [patch 8/9] percpu: " Andrew Morton
2021-09-10  3:10 ` [patch 9/9] mm/vmalloc: " Andrew Morton
2021-09-10 17:23   ` Linus Torvalds
2021-09-10 17:23     ` Linus Torvalds
2021-09-10 18:43     ` Kees Cook
2021-09-10 19:17       ` Linus Torvalds
2021-09-10 19:17         ` Linus Torvalds
2021-09-10 19:32         ` Kees Cook
2021-09-10 19:49     ` Nick Desaulniers
2021-09-10 19:49       ` Nick Desaulniers
2021-09-10 20:16       ` Linus Torvalds
2021-09-10 20:16         ` Linus Torvalds
2021-09-10 20:47         ` Kees Cook
2021-09-10 20:58           ` Nick Desaulniers
2021-09-10 20:58             ` Nick Desaulniers
2021-09-10 21:07             ` Kees Cook
2021-09-11  5:29     ` Joe Perches
2021-09-11  5:29       ` Joe Perches
2021-09-21 23:37     ` Kees Cook
2021-09-21 23:45       ` Joe Perches
2021-09-21 23:45         ` Joe Perches
2021-09-22  2:25         ` function prototype element ordering Kees Cook
2021-09-22  4:24           ` Joe Perches
2021-09-22  4:24             ` Joe Perches
2021-09-24 19:43             ` Kees Cook
2021-09-22  7:24           ` Alexey Dobriyan
2021-09-22  8:51             ` Joe Perches
2021-09-22  8:51               ` Joe Perches
2021-09-22 10:45               ` Alexey Dobriyan
2021-09-22 11:19             ` Jani Nikula
2021-09-22 21:15             ` Linus Torvalds
2021-09-22 21:15               ` Linus Torvalds
2021-09-23  5:10               ` Joe Perches
2021-09-23  5:10                 ` Joe Perches
2021-09-25 19:40               ` David Laight
2021-09-26 21:03                 ` Linus Torvalds
2021-09-26 21:03                   ` Linus Torvalds
2021-09-27  8:21                   ` David Laight [this message]
2021-09-27  9:22                     ` Willy Tarreau
2021-09-10 17:11 ` incoming Kees Cook
2021-09-10 20:13   ` incoming Kees Cook

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=6a84e8b3fa07483092ae79aeded81797@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=cl@linux.com \
    --cc=danielmicay@gmail.com \
    --cc=dennis@kernel.org \
    --cc=dwaipayanray1@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.