I think it’s definitely worth it - it’s significantly more readable Imo 
AstonJ
tmbb
I’ve skimmed through the source of the formatter, which I assume has been run through itself. It’s quite readable (as expected), although it looks “too light”. In does waste a lot of vertical space on blank lines. Because Elixir functions tend to be quite short and most are referentially transparent, they can be understood in isolation and it’s not a disaster if you can’t see as much code at once.
It does lead to more scrolling in any case, but I think that’s something one can live with. Now I’m waiting for all the cool refactoring tools that will be made from this.
1
ryanwinchester
I’m also in the “leave the numbers alone” boat. If I want to use my money (like in stripe) as cents, then it really helps to see it like 120_00 instead of 12000
so far, I like everything else.
4
josevalim
Creator of Elixir
You can have all of them on the same line if you want to:
case foo do
{:ok, bar} -> {:ok, bar}
{:error, baz} -> {:error, baz}
end
But if you have newlines after ->, then the formatter will respect that and proceed to add an empty line between each clause.
Remember the goal of the formatter is to make the code consistent. The opposite of the current behaviour would be to remove lines between clauses, which would affect different areas of @Crowdhailer’s repository. I think users would very likely be more upset if we remove the empty lines they added to space out code.
Between the two below, one is definitely more readable than the other for me (although I agree it is subjective):
defp integer_to_algebra(text) do
case text do
[?0, ?x | rest] ->
"0x" <> String.upcase(List.to_string(rest))
[?0, base | _rest] = digits when base in [?b, ?o] ->
List.to_string(digits)
[?? | _rest] = char ->
List.to_string(char)
decimal ->
List.to_string(insert_underscores(decimal))
end
end
and
defp integer_to_algebra(text) do
case text do
[?0, ?x | rest] ->
"0x" <> String.upcase(List.to_string(rest))
[?0, base | _rest] = digits when base in [?b, ?o] ->
List.to_string(digits)
[?? | _rest] = char ->
List.to_string(char)
decimal ->
List.to_string(insert_underscores(decimal))
end
end
We will open up a discussion on that.
10
Gyllsdorff
Will it be possible to run the formatter in strict/opinionated mode? I.e. “There is exactly one correct formatting standard”?
0
tmbb
Yes, if one has to choose, it’s better to have the newlines every time than to never have newlines.
0
Gyllsdorff
I just have one request: Don’t force us to always use aliases.
We have some modules with names that only makes sense in the context of their parent module, like this
defmodule Foo.Api.Google do
end
defmodule Foo.Authentication.Google do
end
defmodule Foo.Api.Response do
end
defmodule Foo.HttpRequest.Response do
end
For example Credos basic configuration wanted us to use aliases for everything which meant we ended up with references to modules just called Response with no hint if it was a api response or a http request response. In credos case it was configurable by adding this the credos conf, {Credo.Check.Design.AliasUsage, priority: :low, if_nested_deeper_than: 2}.
Some of the standard libs have the same “problem”, what is more readable?
Utils.list()Conn.Utils.list()
Now, I don’t know if you even wanted to correct module / aliases usage with the formatter, but I figured I might aswell raise the issue while nothing is set in stone.
2
tmbb
I’m not sure, but I think the idiomatic approach here is to have modules with names like Foo.HttpResponse and Foo.ApiResponse.
1
Gyllsdorff
Generally yes, but for me atleast it is easier to parse Conn.Utils instead of ConnUtils.
Naming the module Foo.Authenticator.Google instead of Foo.AuthenticatorGoogle (or Foo.GoogleAuthenticator) allows the coder to choose the alias name depending on context. If you are in the borderland where you translate api responses to application responses you might want to use the alias Foo.Authenticator and the module reference Authenticator.Google while if you are in the domain that only handles authenticators then you can use the alias Foo.Authenticator.{Google, Facebook} and Google as the module reference. Of course, some dev use the domain naming scheme and group things by provider context instead like Foo.Google.Authenticator, Foo.Google.Gmail or Foo.Google.Api.
With the module name Foo.AuthenticatorGoogle you are forced to always use AuthenticatorGoogle as the reference even when the context of the call tells the coder it is the authenticator you are calling and not the api, well, unless you use the alias rename feature…
Honestly, I just hate having to use module references like Utils.list(), Conn.Utils.list() is much more understandable.
0
whatyouhide
Elixir Core Team
That’s one of the things I am the most sure we will not do. The purpose of the formatter is get code as consistent as possible, and that would go straight against that purpose.
The underscores between digits in the project were a tough choice and they’re still under review. The rationale behind this was that years and ports look really bad with underscores. However there are still cases that are weird with/without underscores so it’s hard to find something that fits all use cases. We might start keeping what the user used, but we’re not sure yet.
3