Skip to content
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

Warn about re-assigned but not re-used variables #458

Closed
agrimm opened this issue Aug 29, 2013 · 3 comments · Fixed by #469
Closed

Warn about re-assigned but not re-used variables #458

agrimm opened this issue Aug 29, 2013 · 3 comments · Fixed by #469
Assignees

Comments

@agrimm
Copy link
Contributor

agrimm commented Aug 29, 2013

The following code

def reassigned_unused
  a = 42
  b = a.to_s
  a = 56
  b
end

Should be regarded as problematic, because of the second assignment to a which isn't used. It'd be nice if rubocop could generate a warning about it.

I proposed the following as an enhancement for MRI, but it hasn't attracted any attention yet: https://bugs.ruby-lang.org/issues/8691 . The Rubinius team isn't planning on adding this kind of thing to Rubinius itself, based on rubinius/rubinius#2054. The JRuby team isn't enthusiastic about this kind of thing, based on https://jira.codehaus.org/browse/JRUBY-6905

@bbatsov
Copy link
Collaborator

bbatsov commented Aug 29, 2013

I think that such a check makes sense indeed. @yujinakayama Would you look into it?

@yujinakayama
Copy link
Collaborator

👍

Actually I wondered why MRI does not warn about it when I was implementing UnusedLocalVariable. However I was not sure if warning of it is valid at that time, so I've made the cop mimic MRI. But yes, I'll try.

@agrimm
Copy link
Contributor Author

agrimm commented Sep 9, 2013

Thanks for all the work you put into doing this!

It's detected several useless assignments in my application, so it's proved to be useful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants