Underscored variables - which do you prefer, descriptive or not?

I think (a) is better, but I do (b) because I’m lazy.
As longs it’s consistent (over the codebase - use credo), both are OK I think.

I prefer (a) because it saves time.

having done both a and b, now it’s a from now on. b is great, until you come back to the code after a while. @cmo is right, imo.

I do a, however sometime go for b when I have a function with multiple heads and have to repeat a lot of the same stuff.
For example:

def handle_event(event, unsigned_params, socket)

def handle_event("validate", %{"some" => value}, socket) do
  ...
end

def handle_event("save", %{"some" => value}, socket) do
  ...
end

def handle_event("refresh", _, socket) do
  ...
end

def handle_event(_, _, socket) do
  ...
end

...

Agreed with @tomkonidas! Generally if I have 3 or more clauses, I’ll use a function head and then refer to skipped arguments with _.

The exception to that, however, might be very commonly-used callbacks like handle_event/handle_info in LiveViews. Basically if I’m implementing a well-known and oft-used behaviour, I’m more okay using _.

If the function is not a callback, though, I definitely want to see written-out params somewhere. It can be very frustrating to read code that looks like:

def do_the_thing(nil, {_, false}, _, _, meta) do
  ...
end

def do_the_thing([], {true, _}, extra_cool_param, _, meta) do
  ...
end

def do_the_thing([item | rest], _, _, fun, _) do
  ...
end

...

I really enjoy reading through library code when I need to better understand something, and patterns like the above are rather common once you get pretty far “into” a library and are dealing with some kind of under-the-hood data transformation/reduction.

I do A. I always want to know what the var is, not now but six months from now when I revisit this part of my codebase. Super important to me

One argument for (b) is that it should be clear what it does from the function heads that are using it. And for the ones that aren’t using it you don’t care what it is. If you are trying understand the function as a whole there are function heads, docs and type specs.

Seconding this. At best naming an unused variable is a tradeoff. Cost of noise/cognitive load for benefit of reference, but as mentioned there are better places to use as reference. And as was also mentioned, either way you will want to be consistent, and consistently naming all unused vars ends up being a lot.

I think if a function is hard to read because it has a lot of unused variables, that could possibly be considered a code smell. And if refactoring really isn’t possible, function docs are the proper way to justify the tech debt.

I always use (a) because as others already said at one point you revisit the code and are wondering what the hell is the ignored variable. Happens much more often than our present lazy self wants to believe. If I don’t feel like using (a) then I stand up from the computer – obviously I shouldn’t be coding in that mind state!

That being said, (b) is useful when you need a catch-all clause but only if you already exhaustively covered all other cases.

Always a) except in pattern catch-alls where there is no obvious name. But even then I should still do a). Just don’t call it _other .