Uncommunicative{MethodArg,BlockParam}Name fails for *

[denisdefreyne]

Expected behavior

UncommunicativeMethodArgName and UncommunicativeBlockParamName should not trigger when given * as an argument.

Actual behavior

UncommunicativeMethodArgName and UncommunicativeBlockParamName treat a * argument as an offense.

Steps to reproduce the problem

Create a file with contents:

def stuff(*); end

Run Rubocop:

moo.rb:3:11: C: Naming/UncommunicativeMethodArgName: Method argument must be longer than 3 characters.
def stuff(*); end

RuboCop version

4c15154 from Git (past 0.52.1)

[denisdefreyne]

The name of the two cops is inconsistent, too:

UncommunicativeMethodArgName
UncommunicativeBlockParamName

Arg vs Param

[bbatsov]

Maybe we should add an exception about this indeed. But I recall we discussed with others that something like *args is arguably a better name. I know that 9/10 of Rubyists are confused by a naked * and don't know the only use-case for this is to pass the args to super.

Perhaps we can have a different cop to check for this though. Not sure at this point.

[bbatsov]

Arg vs Param

Good catch. Should be Param in both cases. //cc @garettarrowood

[denisdefreyne]

But I recall we discussed with others that something like *args is arguably a better name.

That makes sense.

I recall Rubocop at some point in the past suggesting me to change unused args from *args to *_args and then to *, which I think is the reason why I ended up with the latter.

[denisdefreyne]

don't know the only use-case for this is to pass the args to super.

TIL that you can still pass args to super this way. Point proven!

[denisdefreyne]

Ah, here we go:

class Thing
  def run(*args)
    raise NotImplementedError
  end
end

W: Lint/UnusedMethodArgument: Unused method argument - args. If it's necessary, use _ or _args as an argument name to indicate that it won't be used. You can also write as run(*) if you want the method to accept any arguments but don't care about them.
  def run(*args)
           ^^^^

[bbatsov]

I recall Rubocop at some point in the past suggesting me to change unused args from *args to *_args and then to *, which I think is the reason why I ended up with the latter.

Ah, yeah. Now I remembered this as well. Personally I always used *_args in such situations, as it seemed way more descriptive to me. I guess for some people it's too verbose, though. Anyways, I'm completely open to whitelisting this, even if I think it's not very communicative in general.

[Drenmi]

At the moment, parameters are (incorrectly) referred to as arguments in most of the codebase I think. Perhaps that needs a more sweeping refactoring if it is becoming a problem.

[garettarrowood]

Could someone point me towards an explanation why argument is wrong here? Besides it being all over this codebase, its also referred to method arguments all over Google.

This is not an argument for/against a change. I'm just wondering where the source of truth is with method parameter/argument terminology.

[denisdefreyne]

Could someone point me towards an explanation why argument is wrong here?

As I understand it, a parameter is the name of the variable defined in the method, so thing in the example below is a parameter (not an argument).

def stuff(thing); end

An argument is the value that you pass to a function, so "hi" is an argument (not a parameter):

stuff("hi")

See e.g. this StackOverflow post for some more discussion on the subject.

[denisdefreyne]

The distinction becomes a little vague in this situation:

def run(*arguments); end

arguments is a parameter (not an argument), but I believe that the name is still correct; the arguments parameter after all contains the list of all arguments.

[garettarrowood]

Thanks for the clarification here! I'll change the name of the new cop.

[marcandre]

Does this also handle **?