minhajuddin
While writing Elixir, you are encouraged to start your pipe chain with a raw value. Credo has a check for this at credo/lib/credo/check/refactor/pipe_chain_start.ex at master · rrrene/credo · GitHub
However, I think blindly applying this decreases the readability of the code. Here are a few examples:
Instances where this rule makes sense
# 1
list
|> Enum.take(5)
|> Enum.shuffle
|> pick_winner()
#2
%User{}
|> User.changeset(%{"email" => "danny@m.com"})
|> Repo.insert()
Instances where this rule does not make sense
# 3
User
|> Repo.all
|> Enum.map(fn(user) -> csv_fields(user) end)
|> CSV.encode(headers: true)
#4
20
|> :crypto.strong_rand_bytes
|> Base.encode16(case: :lower)
I think the question boils down to whether you are transforming something. In case of 20 |> :crypto.strong_rand_bytes you are not really transforming 20 into bytes and instead getting 20 random bytes. Just because it is an argument to a function doesn’t mean it is being transformed. What are your thoughts on this?
After writing this, I looked if there was similar discussion elsewhere and found Proposal: Ignore refactoring opportunities in pipe chain when using erlang functions · Issue #14 · rrrene/credo-proposals · GitHub
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #elixirconf-us
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
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.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
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!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
I don’t think enforcing that style is sensible. I just loosely follow the rule.
The following example is what I most dislike with it. Strictly following the rule would mean I need to split up arguments, which really belong to each other. There’s not even a hierarchy in those arguments.
yurko
I consider this issue to be the “perfect is the enemy of good” case, this rule clearly has lots of exceptions but it never makes the code really unreadable. For me the idea is to make the code somewhat cleaner and more consistent as well as to avoid thinking about each particular case.
Because of this I just let credo warn me and blindly comply with this rule which lets me concentrate on other things
minhajuddin
Doesn’t it hamper readability? I find it a bit jarring when I see something like
20 |> :crypto.strong_rand_bytes, it may be because of the way I read the pipe operator, I always read it as transform 20 using this function.yurko
It does, your examples are valid. My point is: It’s not always confusing and not in a big way, for me the benefit of having a consistent way to do things outweigh this cost.
How I read it is “pass (result of) 20 to this function” which might be a bit easier on the brain
easco
I agree with you and I have disabled that check in Credo because I don’t care for the resulting pipelines in many cases.
peerreynders
Depends on your perspective.
I initially didn’t like the style at all and always wanted to start the pipeline with a fully populated function. The way I made my peace with it was to accept that the pipeline is in effect emulating (lambda calculus style) function composition, something that only works when all the functions involved only have a single parameter.
is suggestive of a partial application to bring
Enum.take/2down to an arity of 1. In the case of:crypto.strong_rand_bytesis already at an arity of 1 - so it is ready to be composed as is.This in effect places more emphasis on the composition than the value that enters it.
michalmuskala
I agree, I generally disable this check for credo.