Style Question

I usually do

v = op1
|> op2
|> op3

This leads the code to be condensed, explicit and easy to read. I’ve also seen this way a lot in a lot of Elixir code.

EDIT: I’ve created the tag ‘coding-standards’

https://github.com/niftyn8/elixir_style_guide

I really like the indented style of

first_admins = 
  users
  |> Enum.filter(&User.is_admin?/1)
  |> Enum.take(10)

When you don’t indent there, it is less clear that the pipeline will still end up affecting the value to the left of the equals-sign.

Indentation in Elixir usually don’t matters for execution, but it does significantly affect the readability.

And readability is what I’m most concerned about.

Thanks for that link. I had a link to a different Elixir Style guide as well. I’m asking partially because I’d like to hear if there are points for and points against that style. It strikes me as good coding style but if there’s some strong reason not to use it, I figure the folks here would be most likely to know it.

I honestly prefer the way I described mainly because the code is written with a “block shape”. I find it way easier on the eyes and provided better readability. When skimming over code catching these code blocks from “the corner of your eye” seems to make it easier to remember and associate what the code block does as well. Just my opinion, of course.

Yesterday I actually found that the following piece of code works:

var
|> case do
      :ok    -> 200
      :error -> 404
   end

but I couldn’t find an actual style I enjoyed for it. In these cases I prefer to not use syntactic sugar and shortcuts in order to keep the code in more standard and popular ways of styling.

That’s very interesting @sashaafm. I didn’t realize that sort of code would work.

Interesting that this works. It is a great example of how Elixir is very regular in the syntax it provides (what I mean by that, is that there are nearly now ‘exceptions’ to when certain syntax is possible).

Of course, in the example above, readability is probably improved by extracting the case-statement to its own function.

You can also use the pipe after the case statement.
Here’s an example which includes concatenating the string before sending it to url_decode64 function:
defp urldec64(data) do data <> case rem(byte_size(data), 4) do 2 -> "==" 3 -> "=" _ -> "" end |> url_decode64! end
Now I think that’s really expressive and easy to read. Having said that, I don’t know how many people will agree with me