All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Thomas Monjalon" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>
Subject: RE: Coding Style for local variables
Date: Thu, 20 Jun 2024 08:09:11 +0000	[thread overview]
Message-ID: <978413ec22cb4b76872bd85f3588e5f3@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F53F@smartserver.smartshare.dk>



> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >
> > 10/06/2024 18:31, Konstantin Ananyev:
> > > Morten said:
> > > > The coding style guide says:
> > > >
> > > > "Variables should be declared at the start of a block of code rather than
> > in the middle. The exception to this is when the variable is
> > > > const in which case the declaration must be at the point of first
> > use/assignment. Declaring variable inside a for loop is OK."
> > > >
> > > > Since DPDK switched to C11, variables can be declared where they are used,
> > which reduces the risk of using effectively uninitialized
> > > > variables. "Effectively uninitialized" means initialized to 0 or NULL
> > where declared, to silence any compiler warnings about the use of
> > > > uninitialized variables.
> > > >
> > > > Can we please agree to remove the recommendation/requirement to declare
> > variables at the start of a block of code?
> > >
> > > I know that modern C standards allow to define variable in the middle.
> > > But I am strongly opposed to allow that in DPDK coding style.
> > > Such practice makes code much harder to read and understand (at least for
> > me).
> >
> > Yes it is convenient to know that all variables are described
> > in a known place, just after function parameters.
> >
> > There is also a consistency concern.
> >
> > Old contributors like to be in a comfort zone,
> > 	and we don't want to lose old contributors.
> > New contributors may be refrained by old rules,
> > 	and we would like to get more new contributors.
> >
> > So that's a tricky decision.
> >
> 
> Independent research shows that readability is improved by declaring local variables as close as possible to their first use:
> https://barrgroup.com/72-initialization#footnote12

Hmm... seems  they don't provide any data to back up their statements.
Specially that one sounds weird for me:
" Too many programmers assume the C run-time will watch out for them, e.g., by zeroing the value of uninitialized variables on system startup."
Why on earth people would assume that?
And what exactly means 'too many? 1%? 10%? 90%? 

> 
> Old people (like myself) need to unlearn their bad old habits (originating from limitations in old C standards), and embrace modern
> methods to reduce the risk of introducing bugs.

Allowing to define variables in the middle of the code by itself wouldn't prevent of use of un-initialized variables.
From other side - compilers are quite good these days to catch such bugs.
So I don't think it is a completing argument..    
 



  reply	other threads:[~2024-06-20  8:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 15:10 Coding Style for local variables Morten Brørup
2024-06-10 16:11 ` Tyler Retzlaff
2024-06-10 16:31 ` Konstantin Ananyev
2024-06-20  0:38   ` Thomas Monjalon
2024-06-20  7:53     ` Morten Brørup
2024-06-20  8:09       ` Konstantin Ananyev [this message]
2024-06-20  9:02         ` Morten Brørup
2024-06-20 14:45           ` Stephen Hemminger
2024-06-11 15:10 ` Ferruh Yigit
2024-06-11 15:50   ` Stephen Hemminger
2024-06-17 14:38 ` Bruce Richardson

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=978413ec22cb4b76872bd85f3588e5f3@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=mb@smartsharesystems.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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.