wintermeyer
What do you think about using `_` vs `_other`?
I am used to this syntax for a case structure (my question is about the _ -> part):
case {1, 2, 3} 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 value"
end
A new team member introduced this into our project:
case {1, 2, 3} do
{4, 5, 6} ->
"This clause won't match"
{1, x, 3} ->
"This clause will match and bind x to 2 in this clause"
_other ->
"This clause would match any value"
end
So instead of a _ he/she uses _other. I do know that technically this is no different but I wonder what the majority does/thinks. I don’t want to tell that person in a code review that _other “feels” funny in case everybody but me does it. Every time I see it I stumble upon it but I understand why one would use _other.
Most Liked
zachallaun
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.
bjorng
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.
sodapopcan
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
Last Post!
sodapopcan
This is all fair. I’m all for code consistency and I do use Credo and I was also a RuboCop user for a long time. I think adjustments for team preferences are totally fine so long as you have a process for introducing new rules (as you mentioned). The Elixir community seems to be more accepting of different styles, though, so for me I just consider the formatter law (though many people don’t use it). My problem with linters is exactly what you were saying in your first post: it doesn’t leave room for “it depends” situations where breaking the rules in certain cases makes sense. Of course it would be fairly trivial to write a Credo rule to allow _ for case catch-alls. Same for side-effect throw-aways which I would be extra annoyed to have to name. I actually really like this pattern to mark a call as effectful. It would be super annoying to have _throwaway = fetch() or _effect = fetch() everywhere. Like very quickly you’re going to be like, “Uh, ya, duh!”
But yes, I’m getting very bikesheddy here 
I was on this really amazing team and anything low-stakes like this that came up was decided in minutes or less, so like, I gotta bikeshed somewhere 
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"