-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identify unintended assignment in condition #294
Comments
Technically, there are some valid use cases for constants whose value is determined at runtime (and are nilable). An example for that would be if pwd = Process::INITIAL_PWD
# do something only if INITIAL_PWD exists
end Example use case: https://github.com/crystal-lang/crystal/blob/ed211835f35e354a9047a36aa634a32c01844864/src/process/executable_path.cr#L178 I think this is pretty rare, though. Most constants have static values an non-nilable types. Not sure if there are any considerable examples besides |
This is an idea for a rule that targets the same error type as #163, an unintended assignment in a condition (instead of equality comparison).
I think the only valid use case for an assignment in a condition is for eliminating a
Nil
type from an expression. For that purpose, it's assigned to a local variable and the type restriction excludingNil
applies inside the block.So we could use a couple of indicators which identify this use case:
There might be more indicators.
The original example from #163 would already violate 1), 2), 3) and 5) 😎
I think this approach would be far superior to using Yoda conditionals for this use case.
The text was updated successfully, but these errors were encountered: