Bogus warning: 'for' loop variable is never modified

I loaded up an old solution in ReSharper 5.x, and noticed that this line of
code is flagged.  It's an old ("C") coding style, written by a developer
that left long ago... but the code does work and is fine, and should not be
flagged.  Comments?

string[] directories = Directory.GetDirectories(path);
for (int i=0, ic=directories.Length;i<ic;i++)
        if (directories[i] != path)
                ImportDirectory(directories[i]);

The code "ic=directories.Length" is wavy-underlined with the tool tip saying
that the 'for' loop variable is never modified.

Clicking on it brings up a quick-fix icon with the only option being to
suppress the inspection.

But the control variable is "i", not "ic"... "i" IS modified, and "ic"
should NOT be modified.  So the code, archaic in style as it is, is correct.

I don't know exactly how smart ReSharper can be about this, but perhaps it
could be a little smarter than this.  Or is there really an issue here that
I'm missing (I'm always hesitant to question ReSharper, because it's so
often correct :)



2 comments
Comment actions Permalink

Hello Paul,

We consider any variable declared in the "for" initialization part as loop
variable, e.g. may be they should be synchronously iterated or whatever.
Here, ic is indeed not modified, indicating that there could be mistake like
someone forgot to increment variable. This warning saved my.. emm.. brains
several times :) So the easiest fix would be to move ic out of "for" initialization
part and declare it right before the loop.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


PB> I loaded up an old solution in ReSharper 5.x, and noticed that this
PB> line of code is flagged.  It's an old ("C") coding style, written by
PB> a developer that left long ago... but the code does work and is
PB> fine, and should not be flagged.  Comments?
PB>
PB> string[] directories = Directory.GetDirectories(path);
PB> for (int i=0, ic=directories.Length;i<ic;i++)
PB> if (directories[i] != path)
PB> ImportDirectory(directories[i]);
PB> The code "ic=directories.Length" is wavy-underlined with the tool
PB> tip saying that the 'for' loop variable is never modified.
PB>
PB> Clicking on it brings up a quick-fix icon with the only option being
PB> to suppress the inspection.
PB>
PB> But the control variable is "i", not "ic"... "i" IS modified, and
PB> "ic" should NOT be modified.  So the code, archaic in style as it
PB> is, is correct.
PB>
PB> I don't know exactly how smart ReSharper can be about this, but
PB> perhaps it could be a little smarter than this.  Or is there really
PB> an issue here that I'm missing (I'm always hesitant to question
PB> ReSharper, because it's so often correct :)
PB>


0
Comment actions Permalink

Thanks for the insight.  That makes sense.


"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:c8a88b901c28f88cd2725599a71e6@news.intellij.net...

Hello Paul,

>

We consider any variable declared in the "for" initialization part as loop
variable, e.g. may be they should be synchronously iterated or whatever.
Here, ic is indeed not modified, indicating that there could be mistake
like someone forgot to increment variable. This warning saved my.. emm..
brains several times :) So the easiest fix would be to move ic out of
"for" initialization part and declare it right before the loop.
Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

PB> I loaded up an old solution in ReSharper 5.x, and noticed that this
PB> line of code is flagged.  It's an old ("C") coding style, written by
PB> a developer that left long ago... but the code does work and is
PB> fine, and should not be flagged.  Comments?
PB> PB> string[] directories = Directory.GetDirectories(path);
PB> for (int i=0, ic=directories.Length;i<ic;i++)
PB> if (directories[i] != path)
PB> ImportDirectory(directories[i]);
PB> The code "ic=directories.Length" is wavy-underlined with the tool
PB> tip saying that the 'for' loop variable is never modified.
PB> PB> Clicking on it brings up a quick-fix icon with the only option
being
PB> to suppress the inspection.
PB> PB> But the control variable is "i", not "ic"... "i" IS modified, and
PB> "ic" should NOT be modified.  So the code, archaic in style as it
PB> is, is correct.
PB> PB> I don't know exactly how smart ReSharper can be about this, but
PB> perhaps it could be a little smarter than this.  Or is there really
PB> an issue here that I'm missing (I'm always hesitant to question
PB> ReSharper, because it's so often correct :)
PB>

0

Please sign in to leave a comment.