On Thu, 20 Jun 2024 11:02:21 +0200
Morten Brørup <m...@smartsharesystems.com> wrote:

> > From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> >   
> > > > From: Thomas Monjalon [mailto:tho...@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.

Either way looks ok to me. See no need for hard and fast rules in this area.
But please no patches to change existing code.

Reply via email to