I would declare @spec and in most cases the function head with meaningful argument names. Then I’d avoid noise in function definitions themselves.
@doc """
Recursively iterates list of nodes, amending the accumulator given as a third parameter
according to `byte_count` value.
"""
@spec foo([node()], non_neg_integer(), list()) :: list()
def foo(nodes, byte_count, acc)
def foo([node | tail], byte_count, acc), do: # Some code
def foo(_, _, acc), do: acc
The only thing to be aware of the that the _var are just normal variables so if you use the same one in the function head then you are saying that they must be equal. You can in fact use them as normal variables. Note the compiler will warn you when you do this but be careful.
The _ variable is the only special variable as it always matches and is never bound.
Private functions still deserve the spec. Anonymous functions usually need all the arguments or they are obvious.
I don’t really care as long as what’s going on is relatively clear. We often use @specs in public functions which should encode all the possibilities which is often the better source of truth assuming dialyzer is actually run regularly. For private functions w/o spec though, doing _ or _name is pretty meaningless if you can get the context by looking up/down. The only case where I can see this being annoying is in a PR where the diff doesn’t immediately give full context. I’d argue for application code changes to be reviewed in a text editor where you can bounce around the code anyway, for meaningful changes. Ultimately more context is usually better than less.
_ to me more explicitly says, “we don’t care about this at all and intend to never care”, which means I shouldn’t waste my time thinking about the possibilities for _name, which I tend to appreciate.
The bike shed is a now a vicious violet! Also what Robert said about _ being special was a neat TIL, thanks for that!
Also a TIL for me in that underscore prefixed variables are actually bound (I just played around with it in iex).
Is that actually something that some living code relies on, or is this something Elixir could take the stand on and treat _foobar identical to _?—would that cause problems? The two reasons that come to mind are 1) existing library code (which is immune to warnings_as_errors) and 2) function definitions beginning with an underscore, though I feel those are treated completely differently by the compiler… I’m not actually sure, of course, so am I wrong?
I otherwise can’t imagine a scenario where you should want to match with binding underscores, but maybe a situation like this could be clearer with the underscore:
def foo(%User{id: _same}, %Post{user_id: _same}), do: # ...
…but again, we’re getting the warning anyway and I don’t necessarily agree that this is clearer (and I usually go for the when version anyway even though I think the former is pretty sexy).
Annnnnnyway, In all the time I’ve been annotating my throwaway matches, I’ve never even had the clue that they were actually being bound, so I’m just really curious if this seemingly hidden gotcha could be eliminated without much friction.
So the special handling of the _ variable is defined in the Erlang language while the handling of _name variables is all done by the Erlang compiler. It is where the warnings around the _name variables come from but it quite happily just passes them on.
So if Elixir is to change how the _name variables are to be treated it could cause some confusion. It would just have to be careful how it passes them on.
I also do both. Typically, I prefer self-documenting code, so _name is going to be my default mode, but when you’re grouping function heads correctly, in some cases, like in the catch-all matches at the end of a logical group, names no longer matter. The last clause of a recursion is a simple example where I will throw away ignored accumulators and just leave a single underscore in their stead.
I take mostly from column A with a little bit of column B.
