wmnnd
Readability of single-clause with statements
Apparently Credo considers single-clause with statements with an else branch a readability issue. I’m curious, what’s everybody’s opinion on this?
I think with can actually help readability when implementing a function with a “happy path”:
with {:ok, yay} <- something() do
this_is_the_happy_path(yay)
else
{:error, reason} -> handle_error(reason)
end
The alternative is, of course, to use good ol’ case:
case something() do
{:ok, yay} ->
this_is_the_happy_path(yay)
{:error, reason} ->
handle_error(reason)
end
Which option do you find more readable?
Most Liked
benwilson512
Personal $0.02: For single clauses the case is 100% better because the patterns all line line up and stand out better.
stevensonmt
I would say more like 90% better just because I can appreciate a possible style guide that mandates with statements for consistent error handling. So that way you can easily identify functions that can return an error versus those that just return values that trigger conditional flow.
tomekowal
Funnily enough. The same topic popped in recently when we were upgrading a quite old credo version.
We decided to get rid of the rule.
For me, it depends.
We have a bunch of modules where all the functions are pipelines and only one of them had a single case:
defmodule A do
def a do
with {:ok, a} <- do_a(),
{:ok, b} <- do_b() do
{:ok, b}
end
end
def b do
with {:ok, c} <- do_c(),
{:ok, d} <- do_d() do
{:ok, d}
end
end
def c do
with {:ok, e} <- do_e() do
{:ok, e}
end
end
end
The rule that a single-case with statement should always be rewritten to case did not make much sense in that scenario. Other than consistency, I always pitch for using the simplest tool for the job. Case is simpler than with.
Popular in Discussions
Other popular topics
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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








