[erlang-questions] [ANN] erlang-formatter 1.0.0 (go fmt for Erlang)

[Tuncer Ayaz]

On 30 August 2016 at 09:54, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi,
>
> Sourcer would have some advantages, yes, but it's still in very
> early stages. The goal is to have an AST as compatible as possible
> with the standard one, so for the time being it is less important
> which parser is used. For formatting syntactical correct files there
> should be no difference.
>
> My take on this is that the first step is to define what the right
> way to format code is, in form of a specification or a test suite to
> be passed by the formatter. A big part of this is to decide if
> formatting should be "indentation only" or "full rewrite" or both -

Erlang is an old language, and there is plenty of code written in it,
so we will most definitely not be able to introduce one true style,
and we don't have to. However, we can make one available which is a
strict version of what erlang.el does, while allowing you to derive a
customized version of the formatter.

The most reasonable behavior is:

1. If no options configured, indent only.

2. If a built-in style is selected, reformat. There shouldn't be more
   than two built-in styles, where styl #2 is just a variation of the
   pre-configured style #1. Stuff that needs to be configurable:

   0. Enforcing consistent use of comment syntax, (%%% vs %% vs %).
   1. When to line-break and put each comma-separated item on a
      separate line.
   2. When line-breaking, whether to use leading commas or trailing
      commas. I find leading commas easier to work with because they
      reduce editing errors and are easier to notice.
   3. When to align =, ->, =>, ::
   4. How many spaces should surround :: and =
   5. What to do with trailing comments (single %) if it exceeds the
      configured column limit.

   Given that these things need to be done in a formatter anyway,
   exposing them as tunables should be easy.

> there are arguments to be made for each variant. Another one is
> about how to indent (tabs, spaces, how many) and how wide the page

As long as it's consistent and the tools do it automatically, it's up
to the owner of a code base what leading whitespace style is used, and
given the large body of code out there, we cannot make an assumption
when run without custom config.

> is (80 characters may feel too narrow for today's monitors, but
> sometimes code has to be read/edited on narrow terminals). Different

Too narrow and too wide are both less reader friendly, and having
column limits forces you to avoid deep nesting, which improves your
code. There are developers who can work with >100 column text, and we
cannot assume they don't exist, so this must be tunable even in an
other fully pre-configured style.

> use cases need different configuration, I'm not sure if it's
> possible to have one solution to please everybody.

It isn't possible, but we can provide a built-in style which has
everything but the column limit hard-coded, while being a derivative
of the fully customizable formatter. See above.