On Wednesday, 9 January 2013 at 20:36:16 UTC, Benjamin Thaut
wrote:
After some refactoring I had a series of bugs that came from
renaming class members so that the following situation was
present.
class foo
{
float a;
void doSomething()
{
float a;
a = a * 2.0;
}
}
The local variable a shadows the member a after the refactoring
and therefore this code will no longer work as expected. This
was quite time consuming to track down. So I wanted to ask if
we want to prevent that with a warning or even an error? D does
not allow shadowing of local variables, so why is it allowed
for members?
Kind Regards
Benjamin Thaut
There is a rationale for such checks, but I argue that the place
of these checks is not in the compiler itself, but in a separate
tool.
I don't see a reason why we mix up the correct code (which
compiles) with the non error-prone code (which doesn't do things
that look buggy). These are two different concepts. D as a
systems language and (more importantly) as a powerful
generic-programming-enabled language will need to make
compromises on both sides. A static code analyzer won't have to.
I thing an analyzer for such a flexible language would need to
have different levels of ... pickiness.
I'm giving you java and PMD for example - the static code
analyzer can be made substantially intelligent in such common
places.
So, if we had a solid static code analyzer for D, we wouldn't be
having this discussion at all - just add it as a feature of it.
Which brings me to the question - is there any attempt to build
such a beast for the D programming language? I think such a
community driven tool will be of much value for the language
itself (I learned a lot each time about bad design decisions when
using the PMD with existing java).
I would argue (but this is a very weak argument) that a decent
code editor will be able to visually cue you in the easiest of
situations.
