Am Montag, 5. Januar 2026, 10:08:41 Mitteleuropäische Normalzeit schrieb
Sune Vuorela:
> On 2025-12-29, Friedrich W. H. Kossebau <[email protected]> wrote:
> > --- 8< ---
> >
> > Now, fixing those warnings one finds there are some cases where the
> > shadowing might not really be a critical issue. E.g. names of local
helper
> > variables which are later reused in another deeper scope, with little
> > chance to get this wrong:
> > --- 8< ---
> >
> > [...]
> > auto it = something();
> > if (it)
> > [...]
> > for (...) {
> >
> > [...]
> > auto it = somethingelse();
> > if (it)
> > [...]
> >
> > }
> >
> > --- 8< ---
Anyone? I have seen meanwhile related changes, which were simply using
alternative names in such cases (e.g. index vs. idx). Myself not convinced
these changes improved things in summary...
> cppcheck also have warnings for that.
>
> There is also the
>
> QString Foo::name() const {
> return {};
> }
>
> void Foo::someFunction() {
> QString name = name();
> ....
> }
>
> That we have in quite many places (cppcheck also warns by default on
> these)
Though what is the motivation of this kind of function-shadowing-by-variable
warning? What risks are there when missing out the same name? Given the type
is different here almost always?
A pattern I have seen often in code is using the same variable name for
caching the result of some more expensive getter call for a property, which
has made totally sense when reading the code as human in the given context.
And cannot remember bugs related to any shadowing here:
--- 8< ---
void Foo::someFunction()
{
// cache result of expensive to estimate property
const QString name = this->name();
// do stuff referencing "name" property value multiple times:
// [...]
}
--- 8< ---
So, what motivates people to act on this type of warning cppcheck emits?
And what would be the naming pattern to use here instead, which adds more
value by the risks avoided over the cost of more explicit/cumbersome names?
Cheers
Friedrich
