I always find this something |> IO.inspect() more readable than IO.inspect(something) I really don’t see nothing wrong with piping even when there is only one pipe

If you do

something 
|> do_something()
|> do_something_else()
|> with_additional_param(param)

then what’s wrong with just

something |> do_something()

I think we should not mistake readability with familiarity. Just my 2 cents.

Piping into case is pretty cool, but after I do it, I realize it’s often better for me to wrap that case statement into a function that I can name so it reveals the intention a little better.

I especially don’t like doing it in the middle of a pipeline. I find myself using case statements more often in Phoenix controllers to handle the happy path and unhappy path.

Yep this! I pipe into case statements probably a lot more excessively than I really should… ^.^;

And I pipe into if and other such things as well… >.>

People should be very familiar with piping:

something 
|> do_something()
|> do_something_else()
|> with_additional_param(param)

is essentially equivalent to OO

something 
  .do_something()
  .do_something_else()
  .with_additional_param(param)

i.e. method chaining and fluent interface.

The returned object and implicitly passed this (“parameter”) is replaced with the convention of the “result to the first parameter of the function”. That’s it.

From that perspective I’ve always found

something.do_something()

more pretentious (objects are the “leads”, methods only play “supporting” roles) than

do_something(some_thing)

I mean people always make such a big deal about “functions being first class citizens”. Therefore I have similar misgivings about:

something |> do_something()

And the community style guide happens to agree.

Avoid using the pipe operator just once.

There is nothing messy about:

do_something(some_thing)

which can’t be said about

with_additional_param(
  do_something_else(
    do_something(something)
  ), 
  param
)

which is why

something 
|> do_something()
|> do_something_else()
|> with_additional_param(param)

is preferred.

Oh my…so much code I have to rewrite now! Wow thats something I really…should have…checked.