Proposal/Enhance for Elixir Formatter: Format Options (for Numbers)

[Allen Wyma]

First of all, I'd like to say thanks so much for the elixir formatter. I do like nearly all of the defaults. There's one place that I would like to change:

formatting of numbers.

I'd like to be able to turn off the auto formatting of numbers to add in underscores after every third number.

Reason:

I do have some test data in my elixir files that I use to check information and when I search for certain test data by ID, which is a long number, it won't be found cause of the underscores added to the number.

I can see this being useful if you're working with currency, or numbers with some meaning of counting; it does make the numbers easier to read, but if you're reading like an ID, then it becomes a big difficult to understand.

%{ "specialId" => 100000002 } # => %{ "specialId" => 100_000_002 }

[Louis Pilfold]

I'd like to offer a counter point in that I think the lack of configuration is one of the best things about the formatter as it stands.

Without configuration they're is only one style, and this the is no opportunity for teams to squabble about code style/linter format. It also means that (hopefully) all the Elixir code out the works look (relatively) similar.

I don't think the advantage offered by any specific configuration is worth sacrificing this feature.

I gave a talk at last year's Elixir London on the subject https://youtu.be/g4HXeP_CZbc

Cheers,
Louis

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6f055bb9-3c2d-4d65-9cf4-8904509844b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Lindberg]

I know it’s not the prettiest solution, but if it is really a unique ID you could use an atom (or string) instead:

%{ "specialId" => :"100000002" }

Cheers,
Adam

[Onorio Catenacci]

I wonder (just thinking out loud here) if we could leverage a type spec on the number to tell the formatter to leave the number as is?  I mean it seems as if your issue is that it's treating what's essentially a long string composed of only digits as a number rather than a string. 

I agree with Louis' point.  A formatter that allows for a lot of customization rapidly loses the value of enforcing common conventions on all code that's run through it.
 

[Justin Wood]

Forgive me if I am missing something obvious, but I don't quite understand how the underscores are making your tests fail. The compiler removes them. It is only syntactic sugar for us humans who are bad at parsing long sequences of numbers. Would you be able to provide an example of how these are making your tests fail?

iex(1)> 100_000_002 == 100000002

true

iex(2)> 100_000_002 = 100000002

100000002

iex(3)> quote do 100_000_002 end

100000002

# This test passes

test "underscores in numbers" do

  assert 100_000_002 = 100000002

end

Justin

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/d2eeb293-61b9-4139-84d7-49a7871522ef%40googlegroups.com.

[Norbert Melzer]

No, he did not write that tests are failing because of this, but that he has trouble to search the IDs in his testdata, because on his sheet of paper there is written 100000002, and in his testdata it is 100_000_002. So instead of simply typing the number he has to think and insert underscores at the right places.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/siNPFCNkfrABhDqMwHw5_G5BxiyPsafcXpDqv0g457e7SF5TdpZr71PgeaezlV7T_OQNUYPDlC7Z8pa_kTbGLdwk9e_3L6hhJ-sBHv_CqVw%3D%40protonmail.com.

[Allen Wyma]

I’m okay with the other options, it’s just, to me, I can see numbers that actually have meaning to be split at 3, makes sense. But an ID which is isn’t meant to be split, at least in my mind, shouldn’t be split every three characters.

A DB ID is just an ID, not really carrying any significance when counting other than incrementally telling you which record it is when created.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CA%2BbCVsvRe266R_yRvH_S5cDDetFm_%3DUEH4TKL%3D8Y%3DZiBjdBypg%40mail.gmail.com.

[Xavier Noria]

On Sat, Apr 28, 2018 at 2:10 AM, Allen Wyma <allen...@gmail.com> wrote:

I’m okay with the other options, it’s just, to me, I can see numbers that actually have meaning to be split at 3, makes sense. But an ID which is isn’t meant to be split, at least in my mind, shouldn’t be split every three characters.

A DB ID is just an ID, not really carrying any significance when counting other than incrementally telling you which record it is when created.

The rationale is that integer literals are easier to read if split. A hard-coded database ID is an integer, that's it.

In my experience, hard-coding database IDs you later need to grep is not that common. You grep logs for IDs, but source code... I don't know, I have no seen it a lot. Not even in test suites. Even when there are static records like a table of countries, in the source code you normally access them in a way that does not assume IDs.

I lean on the current trade-off, you get one sensible and uniform choice in the formatter, which to me is the one that makes more sense. And if there's some edge case for which this is not convenient... that's where the trade-off becomes a trade-off :).

[niahoo osef]

Absolutely, maybe the best way is to use fixtures and keep test data out of code if you have so many data rows that you have to use editor search to find them.

[Steve Morin]

Yeah and it’s easy enough to add underscores to the number you want to grep.  If there are choices then you can’t consistently know how to grep in a codebase.

On Apr 28, 2018, at 04:17, niahoo osef <ludovic....@gmail.com> wrote:

Absolutely, maybe the best way is to use fixtures and keep test data out of code if you have so many data rows that you have to use editor search to find them.

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAOcJokpHqxT%2BxGnzoG-Di2es%3Dq9RshYfe32%3DBebDJm2daWY5Kg%40mail.gmail.com.