I know this is a minority opinion, and in fact even I myself would regard the following as an exceptional case rather than the norm, but the following unittest from one of my projects, quoted verbatim, is one reason why I'm skeptical of applying code auto-formatting indiscriminately:

------
    assert("i*10+j:i<>j=3".parseGridSpec.generateGrid[].map!(p => p.value)
           .equal(
    [
                      -30,
                 -21, -20, -19,
            -12, -11, -10,  -9, -8,
        -3,  -2,  -1,   0,   1,  2, 3,
              8,   9,  10,  11, 12,
                  19,  20,  21,
                       30
    ]));
------

The meaning of the first line is unimportant to the topic at hand (though guesses are welcome :-P).  The main point here is that any auto-formatting tool I know of would not only completely destroy the elegance of the above test, but also pretty much remove all visual traces of why exactly this particular case is being tested and why the given values are the correct ones, as opposed to some arbitrary random sequence of integers.


T

-- 
PNP = Plug 'N' Pray

I don't believe in auto-formatting at all really, but for a case like that, you would probably just turn the formatter off for that section.

The ones I'm familiar with all let you turn it off for a segment with a magic comment.

On Thursday, 2 May 2019 at 22:44:51 UTC, H. S. Teoh wrote:
> I know this is a minority opinion,

No it's not, I'm in the same clique. I rather think that people should write with discipline, i.e stick to a brace style, an indent style etc. Then the text looks good but they can permit themselves extravagances when required.

> and in fact even I myself would regard the following as an exceptional case rather than the norm, but the following unittest from one of my projects, quoted verbatim, is one reason why I'm skeptical of applying code auto-formatting indiscriminately:
>
> ------
>     assert("i*10+j:i<>j=3".parseGridSpec.generateGrid[].map!(p => p.value)
>            .equal(
>     [
>                       -30,
>                  -21, -20, -19,
>             -12, -11, -10,  -9, -8,
>         -3,  -2,  -1,   0,   1,  2, 3,
>               8,   9,  10,  11, 12,
>                   19,  20,  21,
>                        30
>     ]));
> ------
>
> The meaning of the first line is unimportant to the topic at hand (though guesses are welcome :-P).  The main point here is that any auto-formatting tool I know of would not only completely destroy the elegance of the above test, but also pretty much remove all visual traces of why exactly this particular case is being tested and why the given values are the correct ones, as opposed to some arbitrary random sequence of integers.
>
>
> T

I never use auto-formatting for pretty much the same reason:

All rules (including this one) have exceptions. And automatic enforcement of any set of rules is inherently incapable of handling reasonable exceptions. In other words: There must ALWAYS be a "manual override".

It's a perfect example of rigid idealism (barf!) vs basic pragmatism.

That said, I do like *some* (though not many) minor formatting things that modern editors can help with: Like when I hit "Enter", and it automatically indents the new line the same as the previous. But that works only because it's only a spur-of-the-moment suggestion, not a tool that's meant to override me. (And frankly, *most* editor attempts at "helping" me are things I regard as some other person randomly taking my keyboard and presumptively screwing around with what I'm doing, such as auto-indenting a whole block when I type '}' or auto-inserting a '}'. I can TOTALLY understand why some people would like that stuff, but it completely breaks my muscle memory.)

Auto-format is for *exactly* two situations:

A. Cleaning up messy externally-developed code so you can read it your own preferred way.

B. Tolerating incompetent team members who are SOOO bad at what they're doing that it's worthwhile to sacrifice some formatting freedom so the idiots on the team will no longer screw up the basic style guidelines so badly, on such a regular basis.

On Thursday, 2 May 2019 at 22:44:51 UTC, H. S. Teoh wrote:
> The meaning of the first line is unimportant to the topic at hand (though guesses are welcome :-P).  The main point here is that any auto-formatting tool I know of would not only completely destroy the elegance of the above test, but also pretty much remove all visual traces of why exactly this particular case is being tested and why the given values are the correct ones, as opposed to some arbitrary random sequence of integers.
>
>
> T

I love autoformatting. I have my VSCode setup to run dfmt on the code on each save, so that my code is formatted properly each time. It also helps me to find missing or misaligned braces, because dfmt goes crazy in such cases and it's easy to spot something is wrong. Also it allows me to type code very quickly, because I don't have to bother with newlines, indentation, I just write my code any way I want, Ctrl+S and I have it all nice and clean.

Yes, the case you mentioned is an edge case, where autoformatting doesn't help. But I rarely encounter such case in my own code. If I have to align arrays like this, I usually read them from a separate file, so that the code formatter can't touch it.

On Friday, 3 May 2019 at 07:48:14 UTC, JN wrote:
> I have my VSCode setup to run dfmt on the code on each save, so that my code is formatted properly each time.

I used such a setup for a TypeScript project, it was nice that it automatically enforced the strict 80-columns limit and made long object literals or function calls look better. There was one time where the linter didn't agree with the result of the formatter, which was pretty funny.

In a C# project the formatter could also sort class field alphabetically, which turned a nice order of:
x0
y0

x1
y1

into:
x0
x1
y0
y1

For D I don't find it hard to write well-formatted code, the only help from a formatter I would want is splitting up long signatures with template constraints or word-wrapping documentation comments (since anytime I insert/remove a word on a line all following lines need to be adjusted).

On Thursday, 2 May 2019 at 22:44:51 UTC, H. S. Teoh wrote:
> I know this is a minority opinion, and in fact even I myself would regard the following as an exceptional case rather than the norm, but the following unittest from one of my projects, quoted verbatim, is one reason why I'm skeptical of applying code auto-formatting indiscriminately:
>
> [...]

As others have mentioned, one can turn autoformatting off or tweak it where needed. Even LaTeX allows one to modify the default behaviour so things look as the author intended them.

On Thursday, 2 May 2019 at 23:26:47 UTC, Basile B. wrote:
> On Thursday, 2 May 2019 at 22:44:51 UTC, H. S. Teoh wrote:
>> I know this is a minority opinion,
>
> No it's not, I'm in the same clique. I rather think that people should write with discipline, i.e stick to a brace style, an indent style etc. Then the text looks good but they can permit themselves extravagances when required.

I like having the formatter available. I have been fun with the auto format in VS C#.

But I do not even care about consistency in where braces live. You can do terrible formats, other than that I don't care.