What do you think about two-space indenting?

I feel this glosses over "enforced by tooling" option. Go ecosystem seems perfectly fine with tabs&spaces. Despite the fact that people like to criticize go, I don't think people complain about tabs often in practice?

2 Likes

FWIW, a bunch of us back in the day came from Ruby, where two space indent is the general standard. We ended up going with four in spite of many of us preferring two.

3 Likes

Good question. I don't know how much people complain about gofmt -- I've certainly seen plenty of people who dislike what rustfmt does to their code, which I suspect makes the tooling argument less effective for them. Maybe Go's intentionally-lower expressiveness means the gap between hand-formatting and automated-formatting is just smaller, so it satisfices?

I guess there could also be a version that doesn't touch internal whitespace and just tweaks the leading stuff, which would be always-correct...

I'd have to double check but I think rustfmt's opinion is that you don't do alignment other then indention, no? So they'd be no reason to mix tabs and spaces?

2 posts were split to a new topic: What do you think about gofmt vs rustfmt?

There's a book I read years ago, Code Complete -- https://en.wikipedia.org/wiki/Code_Complete --, that produced evidence of the impact of indent size on bug frequency. This is the sort of thing that PhD computer scientists write their theses on. As I remember, one-space indent was really bad; two-space rather better; three and four-space better still, and about the same as each other. By the time it got up to 8-space indent, it was as bad as one space again. (I don't think they had examples of any indent conventions apart from 1, 2, 3, 4 or 8.) The thesis referred to C code, but I expect the impact on Rust would be similar. Maybe indent-significant languages like Python or Haskell would give different results.

I've worked with 2, 3, 4 and 8. My least favourite was 8, and I'm pretty happy with any of the others, but 3 or 4 better than 2. My feeling is that if you need 2 space indent because your scopes are so deeply nested, you should be thinking about splitting up your functions a bit more.

An interesting option is what JetBrains MPS does: just save the AST in the most compact format available, and format it for viewing according to the current readers preferences.

Personally I don't like too much spacing, I want to be able to see a lot of code at once if needed, and too much spacing just makes that worse.

Two spaces is fine, that's enough to see the indentation clearly. I'm also fine with tabs, I like them because they're more towards dynamic display like the AST idea. But alignment is a problem.

Ultimately, I don't care that much, but having an automatic formatter is very important, because it saves you from so much unnecessary attention spent on formatting.

2 Likes

Ideologically I prefer tabs a bit more, but this preference is not strong enough to fight against the existing convention. And I certainly don't have a preference towards two spaces, so I will not fight to replace the current convention by it. Regarding the tab+spaces problem, personally I use the following formatting in my code, so the problem does not arise in the first place.

while cond {
    let foo = Builder::new()
        .param1(4)
        .param2(2)
        .build();
    foo.bar();
}
1 Like

I use 2 spaces for things which can reasonably be quite nested: configuration or data, in json, yaml, even xml ( :frowning: ). For code I also agree that it really shouldn't be that nested, so 4 spaces should definitely fit in the screen.

Who knew this topic would be so opinionated?!?

:laughing:
Best editor thread next?

Is it weird that I have no preference at all regarding spaces or tabs, or the number of spaces used as long as they are greater than zero and less than 8?