Rubocop: Unexpected Lint/UselessAssignment for variables which is used as argument with block and without parentheses.

[hkdnet]

Expected behavior

Cop Lint/UselessAssignment allows arguments which used in the method.

Actual behavior

Cop Lint/UselessAssignment does not allow arguments which used in the method.

Steps to reproduce the problem

def some_method(x)
  yield x
end

def foo
  a = 1
  some_method a { puts 1 }
end

a is used as an argumement of some_method but Lint/UselessAssignment is detected at line.6.

Offenses:

main.rb:6:3: W: Lint/UselessAssignment: Useless assignment to variable - a.
a = 1

This also happens with block. Lint/UnusedMethodArgument is detected.

def some_method(x)
  yield x
end

def bar(a)
  some_method a { puts 1 }
end

RuboCop version

$ bundle exec rubocop -V
0.47.0 (using Parser 2.3.3.1, running on ruby 2.3.1 x86_64-darwin15)

[pocke]

Thanks for your feedback!

This is the expected behavior.

If parentheses don't exist, some_method a { puts 1 } is interpreted same as some_method(a { puts 1 }) by Ruby.
So, the a identifier is not used as a local variable. It is used as a method call.

[bbatsov]

I'm actually surprised we don't have some lint cop for situations like
this. Clearly this type of code is quite confusing.

On Tue, Jan 17, 2017 at 22:06 Masataka Kuwabara [e-mail]
wrote:

Thanks for your feedback!

This is the expected behavior.

If parentheses don't exist, some_method a { puts 1 } is interpreted same
as some_method(a { puts 1 }) by Ruby.

So, the a identifier is not used as a local variable. It is used as a
method call.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bbatsov/rubocop/issues/3928#issuecomment-273194214,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGVysghAblVtr9cy9iNHSQD6JrMHcMeks5rTNkEgaJpZM4Llvew
.

[Drenmi]

I'm actually surprised we don't have some lint cop for situations like this. Clearly this type of code is quite confusing.

Didn't a recent PR add parentheses checks for method calls with arguments? 🤔

[hkdnet]

Wow, I'm sorry for this code.
I immediately added parentheses and didn't run it 😢

My problem was solved, but another discussion is just starting.
Should I keep this issue opened?

[Drenmi]

@hkdnet: No worries! Looks like we're discovering opportunities for new cops or to improve existing ones, so let's keep it open for a bit. 😀

[bbatsov]

I've opened a new ticket and I'll close this one.

[pocke]

I'm actually surprised we don't have some lint cop for situations like this. Clearly this type of code is quite confusing.

Didn't a recent PR add parentheses checks for method calls with arguments? 🤔

Yeah, but I think the cop has too wide scope. I think we should add a configuration to detect only the problem(e.g. CheckOnlyWithBlock: true), or we should add a new cop for the problem(e.g. `Lint/MethodCallWithBlockParentheses).

[bbatsov]

we should add a new cop for the problem(e.g. `Lint/MethodCallWithBlockParentheses).

I'd go down this route. The other cop that's on PR has a pretty wide scope and it's unlikely it will ever be enabled by default due to serious potential for false positives there.