It’s probably my time with Clojure showing- collapsed delimiters saves a lot of space and reduces noise when all you’re doing is writing nested data. It’s not as good for reorganizing, though.
mischov
OvermindDL1
Yeah I do end-line closing tags in lisp as well, but that is because the ‘code’ is that way, for formatting data it is often good to see the bounds. ^.^
josevalim
Creator of Elixir
Yeah, we only respect the user’s choice for data structures. We could also do it for function calls but function calls usually give us more liberty to handle those issues, for example by breaking into variables. And there is also the issue with function calls with no parens which have no way of respecting the user’s choice because there are no delimiters…
OvermindDL1
Not really. The times I often use the multi-line function call syntax like that is when it is a macro and the AST is important. Look at ExSpirit for example (hmm, I need to test how elixir would format some grammars…). ^.^
EDIT1: Not very well, the grammar’s got a lot more right-heavy and the trailing comma’s all vanished, which is really important in grammars considering how much they are shuffled around while testing parsing… >.<
EDIT2: Also what on earth is it doing making this format?! o.O
pipe_result_into: List.to_tuple()
|> case do
{:started, datetime_string} ->
{:started, parse(datetime_string, parse_weirddatetimeformat()).result}
result ->
result
end
EDIT3: It turned this:
defrule parse_entry(seq([
parse_type(),
parse_body(),
])), pipe_result_into: List.to_tuple() |> (case do
{:started, datetime_string} -> {:started, parse(datetime_string, parse_weirddatetimeformat()).result}
result -> result
end)
Into this:
defrule(
parse_entry(
seq([
parse_type(),
parse_body()
])
),
pipe_result_into: List.to_tuple()
|> case do
{:started, datetime_string} ->
{:started, parse(datetime_string, parse_weirddatetimeformat()).result}
result ->
result
end
)
First of all, the function definition is all wrapped up in parenthesis, which is just wrong (that is like formatting def blah(x) to be def(blah(x))), and it formatted the pipe_result_into: option with the pipe into a ‘what the heck is this’, as well as a few other oddities (more minor ones like the seq call not being on the primary line and such).
The thing that bugs me most is how it is doing that piping in the pipe_result_into option, it makes me confused as to if it is piping the output of the List.to_tuple() call or if it is piping the output of the parse_entry call. I’m still having issues mentally parsing that even though I know it is fairly obvious… >.<
mischov
Part of why it was so striking to me was a couple lines later another multi-line compare call with literally 2 more characters was not collapsed, and so now I have two visual representations of something that should stand out visually as (no pun intended) comparable.
This is how the formatter leaves this.
def eval(%Expr.Comparative{op: :!=} = expr, node, document, context) do
v1 = Expr.eval(expr.e1, node, document, context)
v2 = Expr.eval(expr.e2, node, document, context)
compare(expr.op, Expr.Helpers.eq_fmt(v1, v2, document), Expr.Helpers.eq_fmt(v2, v1, document))
end
def eval(expr, node, document, context) do
v1 = Expr.eval(expr.e1, node, document, context)
v2 = Expr.eval(expr.e2, node, document, context)
compare(
expr.op,
Expr.Helpers.cmp_fmt(v1, v2, document),
Expr.Helpers.cmp_fmt(v2, v1, document)
)
end
I guess one could argue there is a difference between the two versions of the function that it now better highlighted, but it seems off to me.
That’s true, but in this case I purposefully chose to use a multi-line function call rather than adding two more variables because I felt it produced the clearer code.
josevalim
Creator of Elixir
There is an option for declaring locals_without_parens, it is in the docs.
For the keyword, we need to do something but I am not sure what. Probably treat it in the same way we would treat =. In this case it would mean breaking into the next line and indenting with two spaces. Please open up an issue.
Good point, please open up an issue too!
OvermindDL1
I could define that in ex_spirit sure, but how would the users use it without each-and-every-single-one-of-them adding it to their options as well? It should be some in-file definition, like a module attribute or something to state ‘all uses of this is without parenthesis’ or so.
That would work but is more wordy in this case (more so in other cases as they tend to be really short, this example is longer than most).
OvermindDL1
The above formatted to this without the parenthesis:
defrule parse_entry(
seq([
parse_type(),
parse_body()
])
),
pipe_result_into: List.to_tuple()
|> (case do
{:started, datetime_string} ->
{:started, parse(datetime_string, parse_weirddatetimeformat()).result}
result ->
result
end)
However, why is it indenting it *so*far*to*the*right*? o.O?!
That action is making some of the deeper grammars very unreadable (especially as it is making the lines longer due to some other changes as well). Inside a (/) should be indentation, not alignment (absolutely should not be alignment).
So I can either get parenthesis around the rule function definition, or I get everything pushed waaaaaay over to the right. Neither of these options are right, not right at all… O.o!
tmbb
I’ve been playing with ExSpirit a lot. It’s a great library but it’s fundamentally weird. It does unconventional things to the AST. It’s a great DSL but it doesn’t mesh exactly well with the wider Elixir code. I dont’ think any effort should be expended in improving the output of the formatter on ExSpirit.
EDIT: ExSpirit is great for reasons other than the DSL, I don’t want to imply that the DSL is the only (or even major) reason you should pick ExSpirit!
Most of the time I actually put the seq in its own line, but as I’ve said above, I don’t think normal formatting rules apply to ExSpirit. Maybe ExSpirit need its own style guide? xD I don’t think you should ever expect good results out of running the formatter on ExSpirit.
I agree, this is weird. But again, see my point above.
seanc
In the Javascript ecosystem (where I spend my professional life) we have a formatter called prettier. It’s used in quite a few popular codebases, albeit completely opinionated except for a few tiny options:
- Print Width
- Tab Width
- Tabs or Spaces
- Semicolons or no Semicolons
- Single or Double Quotes
- Trailing commas or no trailing commas
- Bracket spacing
{thing: true}vs{ thing: true }
We make do with these options (I just converted several repos to prettier at my work) and no one really complains because we auto-format inside our CI pipelines.