XS1717 warning

[leon-ts]

Hi,

Code snippet:

Code: Select all

FOR dwRow := dwRow UPTO dwMaxRow
...
NEXT

The compiler displays a warning: XS1717 Assignment made to same variable; did you mean to assign something else?

The variable (field of class) dwRow before the loop has a calculated value. For optimization, loop processing is performed starting not from the first line, but from an already known value. For example, from the specified row number of the table to the end.

Of course, I can write in a different way.

Code: Select all

LOCAL dwNewRow AS DWORD
FOR dwNewRow := dwRow UPTO dwMaxRow
...
NEXT
dwRow := dwNewRow

But the original fragment is a legal trick in programming.
Is it possible that this warning will be fixed for such code?

Best regards,
Leonid

[robert]

Leonid,
This warning messages comes from deep within Roslyn. I will see what I can do, but it may be difficult to detect when the assignment to the same variable is valid and when not.

Robert

[FFF]

Leonid,
it may be legal, but i wouldnt do it. The decision, if you have a typo or not depends on "your" background knowledge. Any other, or you yourself in maybe a year - may not have this knowldedge handy.
Good code is self documenting as far as possible... As you have an assignment anyway, i doubt there's any measurable penalty in the LOCAL dwStartRow declaration...
YMMV

[leon-ts]

Robert,

Maybe in loops (FOR) this is always correct? But as for me, the best option would be to leave a warning, but to divide it into two separate ones: XS1717 - outside the loop, XSNNNN - in the loop (FOR). In this case, it will be possible to add a warning for the loop (FOR) to the "Build Suppress Specific Warnings" section.

Leonid

[leon-ts]

Studies have shown that C# behaves the same:
for (i = i; i <= maxrow; i++) {}
a warning will be generated.

But in C# there is an opportunity to skip the initializer:
for (; i <= maxrow; i++) {}
which will mean the same action, but without warning.

In general, I can always do this:
FOR dwRow := dwRow + 0 UPTO dwMaxRow

It's not a problem.

[Chris]

In my opinion, it is better to leave this as a warning also in FOR statements, because I think that in most cases this will point to an actual typo in the code.

But for cases where the code is written as intended, it would be nice if the compiler supported locally suspending this (or any other) warning with a directive, we have already talked about it and might be available in one of the next builds.

[leon-ts]

Chris,

Good idea!

Best regards,
Leonid