All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	ksummit@lists.linux.dev, Dan Williams <dan.j.williams@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by cleanup.h
Date: Tue, 25 Nov 2025 07:32:24 -0800	[thread overview]
Message-ID: <20251125073224.30e24755@phoenix.local> (raw)
In-Reply-To: <7b37e1cb-271e-49fe-a3ee-5443006284e1@p183>

On Tue, 25 Nov 2025 17:25:19 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Tue, Nov 18, 2025 at 11:39:26AM -0500, James Bottomley wrote:
> 
> > So which should we do?  
> 
> The best way to understand that C89 style of declaring in the beginning
> of the function is pointless rule is to write some code in a language
> which doesn't enforce it. You should see that nothing bad happens.
> 
> It increases bug rate due to increased variable scope allowing typos.
> 
> It bloats LOC -- in many cases declaration and initializer can fit
> into a single line.
> 
> It prevents adding "const" qualifier if necessary.
> 
> Pressing PageUp and PageDown when adding new variable is pointless
> busywork and distracts, breaks the tempo(flow?) so to speak.
> 
> C89 style provokes substyles(!) which makes adding new variables even
> more obnoxious: some subsystems have(had?) a rule saying that declarations
> (with initializers) must be sorted by length, so not only programmer has
> to PageUp to the beginning of the block, but then aim carefully and
> insert new declaration.
> 
> None of this is necessary (or possible) if the rule says "declare as low
> as possible".
> 
> There was variation of this type of nonsense with headers (not only it has
> to be sorted alphabetically but by length too!)
> 
> There is no practical difference between code and declarations:
> declarations can have initializers which can be arbitrary complex,
> just like "real" code. So the only difference is superficial.
> 
> 
> C89 declaration style is pointless and dumb, no wonder other programming
> languages dumped it (or never had), it should be simply discarded.
> 
> It will also make Linux slightly less white crow to newcomers
> (C++ doesn't have this rule after all).
> 

Agree with everything you said.
But I don't want to see patches that are just to rearrange existing
code to move declarations around. So yes, but no more churn please.

  reply	other threads:[~2025-11-25 15:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 16:39 Clarifying confusion of our variable placement rules caused by cleanup.h James Bottomley
2025-11-18 17:18 ` Bart Van Assche
2025-11-18 18:38   ` Linus Torvalds
2025-11-18 19:04     ` Bart Van Assche
2025-11-18 19:14       ` Linus Torvalds
2025-11-18 20:43         ` Al Viro
2025-11-18 19:15       ` H. Peter Anvin
2025-11-18 19:11     ` H. Peter Anvin
2025-11-18 19:16       ` Linus Torvalds
2025-11-18 19:19         ` H. Peter Anvin
2025-11-18 19:17     ` Steven Rostedt
2025-11-18 19:22       ` Linus Torvalds
2025-11-18 19:56         ` Steven Rostedt
2025-11-18 20:23           ` Linus Torvalds
2025-11-18 21:05             ` Linus Torvalds
2025-11-18 20:21       ` James Bottomley
2025-11-18 20:30         ` Linus Torvalds
2025-11-18 20:51         ` Steven Rostedt
2025-11-18 21:10           ` James Bottomley
2025-11-18 22:34             ` Steven Rostedt
2025-11-18 23:32               ` James Bottomley
2025-11-18 19:23 ` H. Peter Anvin
2025-11-18 20:28   ` James Bottomley
2025-11-25 13:09 ` Jani Nikula
2025-11-25 14:25 ` Alexey Dobriyan
2025-11-25 15:32   ` Stephen Hemminger [this message]
2025-11-25 16:04   ` Steven Rostedt
2025-11-25 17:57   ` H. Peter Anvin
2025-12-31 12:17   ` Andy Shevchenko
2026-01-02 14:50     ` Steven Rostedt
2026-01-17 16:23       ` Alexey Dobriyan
2026-01-17 16:54         ` Bird, Tim
2026-01-17 23:32           ` David Laight
2026-01-18 16:04         ` Steven Rostedt
2026-01-18 19:12           ` Paul E. McKenney
2026-01-18 19:17           ` James Bottomley
2026-01-18 19:33             ` Dan Carpenter
2026-01-18 19:52               ` Joe Perches
2026-01-18 21:07             ` Steven Rostedt

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=20251125073224.30e24755@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=adobriyan@gmail.com \
    --cc=dan.carpenter@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=ksummit@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    /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.