Running the new Elixir formatter

I agree with this point because I use a lot this kind of number format all over the project.

I this the library you used?

I hope this is a bug.

No, as far as I understood, he used mix format which is available in Elixir 1.6

Yes I installed the latest version of Elixir from master.

It’s nice because I am running my project on 1.5, i.e. stable, in a docker container but having 1.6 on my machine means that when editing that project atom is using 1.6 to provide formatting.

Oh, so it is this one in the main Elixir repo. Nice, next release will certainly be interesting.

It seems to have the code for inserting underscores in integers if the number of digits are >= 6. I wonder if we can change that to >= 4.
https://github.com/elixir-lang/elixir/blob/425cebf10c24193f42187664dae6aaa8dbe4486f/lib/elixir/lib/code/formatter.ex#L1352-L1363

Please don’t… I was born 1981, not 1_981…

And our http-port number is 20_693, not 20693, sometimes the format depends on the context and not on the data type.

That’s kind of what I meant when I said:

Nice, next release will certainly be interesting.

It will be impossible to satisfy everyone. But I agree, >= 4 might be too short.

Looks good

I would have normally done this:

  defp receive_data(packet, state = %{status: {:chunked_body, :response}}) do
    {chunk, rest} = HTTP1.pop_chunk(packet)
    case chunk do
      nil ->
        {:ok, {rest, state}}
      "" ->
        send(state.worker, {state.channel, Raxx.trailer([])})
        {:ok, {rest, state}}
      chunk ->
        fragment = Raxx.fragment(chunk, false)
        send(state.worker, {state.channel, fragment})
        {:ok, {rest, state}}
    end
  end

And the formatter does this:

  defp receive_data(packet, state = %{status: {:chunked_body, :response}}) do
    {chunk, rest} = HTTP1.pop_chunk(packet)

    case chunk do
      nil ->
        {:ok, {rest, state}}

      "" ->
        send(state.worker, {state.channel, Raxx.trailer([])})
        {:ok, {rest, state}}

      chunk ->
        fragment = Raxx.fragment(chunk, false)
        send(state.worker, {state.channel, fragment})
        {:ok, {rest, state}}
    end
  end

Which, looking at it now, is far more readable

Well I also have several pieces of code which have prices 120_00.

For what it’s worth, my opinion on the changes. It’s mostly negative (warning, 100% subjective unless marked):

I like this convention too. Keeps together functions heads that belong to the same function, which directs my eyes to logical groups of clauses. But the new output doesn’t shock me, except for the problem of taking more space.

Like @AstonJ said above, this might increase readability a little, I don’t know. But it does take away more vertical screen space for sure, which is a bad thing. I’m not sure whether the negatives outweigh the positives here. The question of taking up more space is the only “objective” argument I want to bring to the table. Maybe the trade-off is worth it, and maybe it isn’t but wasting valuable vertical screen space is not just a matter of personal preference

No opinion on this one. Brackets or no brackets, any choice would be ok.

Please don’t… This is one of those places where the programmer’s intent is expressed through formatting. Sometimes, 12_000 is more readable than 12000, sometimes it’s the opposite. I think this should be left up to the programmer. Sometimes you want 1200, sometimes you may want 1_200 and sometimes 12_00 (value in cents, or something like that).

Or is it one of the goals of the formatter to make sure that two blocks of code that compile to the same AST (module line numbers) will always produce the same output? If this is a goal to aim for, then I think I can accept the disruption of the underscores.

This takes up more valuable screen space for very little benefit, I think. What’s the reasoning behind this rule?

There are some obvious improvements in the source that @Crowdhailer didn’t bother to mention, like minor whitespace issues, and for those things the formatter is great.

My main argument against this might be a vague personal distaste against prescriptive code formatters: everybody prefers to edit text instead of AST nodes directly, but then we make all this effort to make the code as uniform as possible to preserve consistency. It’s almost as if we should have been writing AST nodes all along? Or Lisp? You don’t get many discussions on how to format that…

Finally, despite what I’ve said above, having a code formatter is pretty cool, especially if it can convert from AST to code, because it opens up exciting possibilities for code transformation tools that are aware of the AST. This can be useful for project generators, because it would make it easier to add code to the middle of a module and even for refactoring tools. It would make changing a module name over the whole code base almost trivial, for example: It could just compile the modules, replace the appropriate alias and write the changes to disk. It might have some corner cases I’m not aware of, but it would certainly make this kind of thing much easier. It would produce nice diffs, of course, because the code would have been formatted already. For renaming a function it wouldn’t go as well:

variable = MyModuleAlias
new_variable = variable.function_i_want_to_rename(arg)

or even worse:

def f(my_dynamic_module_alias, arg) do
  my_dynamic_module_alias.function_i_want_to_rename(arg)
end

but with the help of mix xref or even access to the elixir manifests or the erlang core output it might make a passable job. I hope the formatter will be made available as a standalone tool that can be used on the AST for these purposes.

Having a code formatter that is well tested and guarantees it’ll keep the semantic meaning of the code is much better than not having one, no matter how much I disagree with the space-wasting “features”.