Scope of variables flagged by code inspector

Chris Johns chrisj at rtems.org
Mon Oct 11 23:43:07 UTC 2021


On 11/10/21 10:14 pm, Sebastian Huber wrote:
> Hello Zack,
> 
> On 10/10/2021 20:25, zack leung wrote:
>> I recently was invited to look at a new code review tool by Joel. It's used
>> to help with reducing technical debt. It suggests various fixes and
>> highlights various possible errors. One of them relates to the fact that
>> some of the variable scopes and be reduced. For example, we can define
>> variables when they are needed not at the beginning of functions. I don't
>> know if it matters much. Maybe it helps with memory due to the timing of
>> things allocated on the stack.  This also helps with the compiler not
>> needing to analyze long lifespans. This also prevents the variable to be
>> flagged as uninitialized.
> 
> I guess modern compiler don't care about when you define a variable. It is
> probably more an issue for the human reader.
> 
>> But personally, I feel it's easier to read if we don't change where
>> variables are defined. An example of this is found in
>> testsuites/mptests/mp09/task1.c. An array called recieve_Buffer could be
>> defined later. I'm not sure if this matters much. I want to know your
>> input.
> 
> Moving the variable to the most local scope is already covered by the current
> coding style (I hope). Maybe this needs to be clarified in the coding style.
> 
> From my point of view we should go one step further and allow the declaration
> and preferably also the initialization of local variables as close to their
> first use as possible in contrast to only the scope begin.

I am OK with this if we have a suitable means to detect and handle shadowed
variables.

Chris


More information about the devel mailing list