Citation needed!
Credo is for enforcing per-project standards, not general community standards, and can be customized (which is what I do).
Also, check the root module module of Phoenix:
https://github.com/phoenixframework/phoenix/blob/7d5b954/lib/phoenix.ex#L12-L13
We practice documentation as code, so we encourage commenting ignored pattern matches like _error to better explain the variables:
case result do
{:ok, data} -> do_action(data)
_error -> fail()
end
If you’re literally talking about writing _other, that’s something we would avoid and would try to come up with a better name since “other” is what _ -> means. The goal is to document the program, not the programming language.
In the spirit of documentation as code, I write:
case result do
{:ok, data} -> do_action(data)
{:error, _} -> fail()
end
This leaves little up to the imagination of an unsuspecting reader: they can see the exact shape and don’t have to look anything up. It also means we get a more meaningful exception if somehow we get nil or something else completely unexpected (the entire case fails the match as opposed to the catch-all failing the match). Even with safety nets we have, Elixir is still a dynamic language so anything is possible!
For me, a bare _ perfectly conveys “I literally don’t care what I get here, even if it falls outside of the subset of things I’m assuming it’s going to be.” Otherwise, if you’ve been writing Elixir for more than a minute and you don’t know that the opposing match of an :ok tuple isn’t some form of :error then that’s a whole other problem and naming your matches as such isn’t going to fix that.
I say that if you know the shape of the error, match on the shape! There is confidence in a bare _ that proclaims: “I will literally accept any outcome!” whereas _error sorta says “Well, you know, I’m assuming this is going to be an error tuple… like, probably.”
Please note, I’m fully aware I’m being way too overly passionate about a low-stakes stylistic point 
I’ll do whatever a codebase’s style guide dictates I must do.
Hmm… I use Credo on pretty much everything and _ for placeholders both in function heads and to avoid Dialyzer unmatched return complaints… But I don’t recall seeing the Credo warning you speak of. Are you sure this is stock/default Credo?
Not quite exact f.ex. I’d also do {:error, _atom} for the sake of the future me (or another dev) who would want to do something with the value sometime in TheFuture™. Could save them some time looking up the API’s @spec-s.
Let me introduce you to Integer.parse/2 
case Integer.parse(input) do
{int, ""} -> "all good"
{_int, _string_remainder} -> "oops, only partially an integer"
:error -> "sorry, not an integer at all"
end
Ahh, it’s disabled by default. Definitely enabled at my current job (with about a dozen Elixir projects). Pretty sure it was enabled at my last job too though it’s been a few years now and hard to remember for sure.
Well, maybe that’s my decade plus in Ruby-land showing through. Even though I left Ruby behind almost 6 years ago, I still have RuboCop PTSD.
Both RuboCop and Credo allow customizing rules but I’ve always felt that there was a strong impetus to adopt the defaults and keep customization to a minimum. I definitely felt that way while working hard to keep RuboCop happy back in my Ruby days.
I mean, if you make Credo or RuboCop a PR check then you have to conform to the rules in order to get your work merged and complete stories. And I don’t think that’s a bad thing (the RuboCop PTSD was because I felt that it went too far and was often a source of a lot of friction). Bike-shedding is best avoided at all costs. Consistency and readability of code saves a lot of mental overhead.
But, still, not everyone gets a say in the linter rules so you have to follow them and it sets a standard. But I think I’m misremembering this one; a) it’s not on by default (as I indicated in another response here) and b) like the Phoenix example you shared, there is clearly plenty of important code out there still using bare “_”.
So I’m changing the nature of my chiming in here: “Hey y’all, if you want to settle this and codify it in your codebase, there’s a Credo check: Credo.Check.Consistency.UnusedVariableNames — Credo v1.7.19” 
Just to make it perfectly clear, this is not an optimization, not even a slight one. The Erlang compiler can see when a variable is unused and will emit the same code for matching _ as when matching _other or some other variable that is never used. Actually, to avoid having to handle _ as a special case, the Erlang compiler replaces _ with a freshly created variable that will never be used.
Ehn, fair, but I don’t think this adds too much. That’s it’s “unwrapping” an error tuple is all the information I need, though I dunno, I’ll think about it next time I’m in this situation.
Well s 
t, fair enough!
Oh good to know, thank you!!
