Stream: ideas

Topic: alignment in the formatter

Richard Feldman (Dec 06 2023 at 14:37):

currently, roc format doesn't do anything with alignment - that is, trying to make parts of code visually line up.

in contrast, rustfmt will do things like this:

let foo = "blah"; // comment starts here
                  // ...and continues here

Richard Feldman (Dec 06 2023 at 14:38):

I've also seen sometimes people will align things manually in order to make it more obvious how things fit together, e.g.

[
    foo  bar   baz,
    blah stuff etc,
]

Richard Feldman (Dec 06 2023 at 14:39):

we've never really talked about it, but I'd like to discuss this general idea

Richard Feldman (Dec 06 2023 at 14:42):

for example:

• what if the formatter let you extra spaces around, but only if there's a space character immediately above or immediately below it (indicating that it's for alignment, as opposed to just a stray space) - note that a downside of this is that some people will likely use this to do their own preferred alignment style (e.g. someone could do this, which would presumably result in the types of stylistic arguments among teams that code formatters can prevent)
• what if the formatter deterministically inserted some spaces sometimes, like rustfmt does for aligning comments? If we wanted to do that, under what specific scenarios would we insert spaces?

Anton (Dec 06 2023 at 15:28):

I like nice alignment but I'm hesitant to make changes here before people find it annoying enough to complain about it :p

Ryan Bates (Dec 06 2023 at 23:14):

I personally don't like this type of alignment. I find it unpredictable, but that's largely a personal preference.

The only concrete thing I have against it is changes in one line affect others which leads to larger git diffs.

LoipesMas (Dec 06 2023 at 23:20):

I've got the feeling that it's impossible to get right and easy to get wrong. Something like a no_format directive or symbol, that disables formatting for the next paragraph, might work better, but that's less pretty and still can be "abused".

Isaac Van Doren (Dec 06 2023 at 23:36):

The only concrete thing I have against it is changes in one line affect others which leads to larger git diffs.

That is a fair point

Sky Rose (Dec 06 2023 at 23:38):

My 2 cents:
There are occasionally times when alignment makes sense, but only when doing weird stuff like drawing diagrams in comments or hard coding tabular data. Doing any alignment as a normal part of code is just a recipe for large git diffs, and code shoved off the right side of the screen.

as an example, maybe

a  = 1
a2 = 2

is reasonable, but

a                         = 1
variable_with_a_long_name = 2

is not, and I don't want the formatter to ever try to guess whether it's okay.

Based on that, I like the approach of a /// disable_formatter / /// resume_formatter comment, where either the formatter is in charge, or you're doing something weird and you're in charge.

Based on experience with these sorts of comments for overriding eslint and other linters, having them scattered around the codebase is fine aesthetically, provides a bit of friction so you only do this when you actually need the alignment, and gives a place to explain why you need to do the override.

Oskar Hahn (Dec 07 2023 at 10:10):

I like the way go fmt adds the alignment. I could not tell, how it does it. But it feels right most of the time.

It is true, that it adds larger diffs. Here is a diff in a go struct, where a new attribute with a longer name was added: https://github.com/OpenSlides/openslides-vote-service/commit/b191025f5c44d4d841b40e7f3c7c71441d299fa8#diff-b68cf559c6f7d294501e1a2fadf19f000bfff841a2860a086ea6555dbf9cef3bR464-R478

It is hard to see, what changed.

But I nevertheless like, that go adds the alignment.

Agus Zubiaga (Jun 22 2024 at 21:59):

So alignment in general is pretty hard, but what if we started with just aligning record fields?

Agus Zubiaga (Jun 22 2024 at 22:00):

I'm struggling to come up with cases where that isn't a clear win

Agus Zubiaga (Jun 22 2024 at 22:12):

I'd group consecutive fields with single line values and align each group. So if you have a multi-line field in the middle, the alignment would start over in the next single line field. I believe that's how go fmt does it.

Sam Mohr (Jun 22 2024 at 22:12):

I would just recommend considering 2 things with aligning record fields:

• Consider a length disparity limit, and ignore overlong elements
• Consider breaking the alignment at every comment, so that groups can be intentionally separated out

Agus Zubiaga (Jun 22 2024 at 22:13):

IIRC go fmt also allows blank lines to break the alignment

Sam Mohr (Jun 22 2024 at 22:58):

That too, yes

Last updated: Jun 16 2026 at 16:19 UTC