What do you think about using `_` vs `_other`?

In this case, I would use _ because the word “other” adds no additional context or meaning.

I do tend to prefer the named variant in function heads with multiple clauses. For instance:

def some_function(:explicit_match, _right), do: ...
def some_function(_left, :explicit_match), do: ...
def some_function(left, right), do: ...

This can be helpful especially with longer function heads that take, say, 4+ arguments, as multiple _ can get a little hard for me to parse visually.

Actually I did use _other a few times, but now that I think about it I probably just should have used _.

It’s probably part of an inner monologue just like when people abuse the then function because it fits the inner monologue?

Just want to +100 this as it’s one of my biggest pet peeves. Like, no %#$@ it’s “other.” When it comes to scanning unfamiliar code, this type of thing is just distracting. If I see _some_var, I think that something useful is being communicated. As already said, _other as a catch-all is not at all useful.

And, technically they aren’t equivalent as _other gets bound whereas _ doesn’t. I’m not advocating that is some sort of meaningful optimization, just sayin’

Yeah, I dislike _other as well but many others are valuable i.e. you have a long chain of matching that checks for several types of structs / maps and then ultimately it’s fine if below you have _not_a_map -> ... – and variations of that. A proper unused variable name really helps code readability.

Absolutely, that’s what I was trying to convey. Another way to look at it is that matching is basically (albeit not strictly) assignment—you wouldn’t called a variable other (at least I hope you wouldn’t). So long as there is a name that makes sense I name my _s, which is the vast majority of the time.

To take this a bit further, due to Elixir being dynamic I’d vouch for writing OP’s example like this (depending on context):

case tuple do
  {4, 5, 6} ->
    "This clause won't match"
  {1, x, 3} ->
    "This clause will match and bind x to 2 in this clause"
  {_, _, _} ->
    "This clause would match any 3-tuple"
end

and if nil is allowed, add a specific nil clause. This makes it very clear what is expected an errors out quickly if it gets junk.

With multiple clauses in pattern plain _ is even more important as:

case {1, 2} do
  {_other, _other} -> :doesnt_match
  {_, _} -> :match
end

Oh ya, good point!

You’ll at least get a compiler warning if you do that, though.

EDIT: wait, no you won’t since _other, _other binds as I even pointed out earlier

You actually do get a warning in this case:

> mix compile
    warning: the underscored variable "_other" appears more than once in a match. This means the pattern will only match if all "_other" bind to the same value. If this is the intended behaviour, please remove the leading underscore from the variable name, otherwise give the variables different names
    │
  4 │       {_other, _other} -> :doesnt_match
    │                ~
    │
    └─ lib/compile_test.ex:4:16: CompileTest.my_fun/0

Well I should probably stop snap-responding then

Kinda surprised no one else pointed this out but if you use Credo on your project (and you should) then – unless you’ve suppressed the rule – it will give you a warning for just ‘_’ and tell you to give it a more meaningful name.

Now “other” may not be the most descriptive variable name, but without better context of what sort of thing you are actually matching it will do in a pinch.

The TL;DR though is that Credo is the compendium of idiomatic Elixir choices and a bare underscore for a variable name is not idiomatic.