You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
simple: take assignments to blank identifiers into account #1106
The code was probably either written before for range was legal or by someone who doesn't know about it. I would expect the code to trigger S1005 or a similar check, but it doesn't, probably because of how the value is “explicitly” unused. Of course, someone could leave it for ease of local debugging, but it still seems like something that people should generally avoid in published code.
There's also a distinction to be made between flagging this in S1005, and flagging assignments to blank identifiers on a general basis. The former might be acceptable for simple while the latter isn't.
#253 is related, but not identical. #253 is concerned with removing assignments that are entirely redundant. That is, simply removing it will not cause compilation to fail. What you're asking for goes a step further. It wants to remove an assignment even if (or especially if?) it requires changing the surrounding code. I'll keep both issues for now.
Activity
dominikh commentedon Oct 27, 2021
It can probably go at least into
aggressive. I am less sure aboutsimple.Related: #253
dominikh commentedon Oct 27, 2021
There's also a distinction to be made between flagging this in S1005, and flagging assignments to blank identifiers on a general basis. The former might be acceptable for
simplewhile the latter isn't.ainar-g commentedon Oct 27, 2021
Issue 253 looks very relevant, thanks. In fact, feel free to close this issue as a dup or merge it into that one.
I'm fine with it being in the aggressive checker instead of the plain simple.
dominikh commentedon Oct 27, 2021
#253 is related, but not identical. #253 is concerned with removing assignments that are entirely redundant. That is, simply removing it will not cause compilation to fail. What you're asking for goes a step further. It wants to remove an assignment even if (or especially if?) it requires changing the surrounding code. I'll keep both issues for now.