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