What do you think about two-space indenting?

community
21

You are of course correct, I did mean Unicode, not utf8. But is there any instance where rustc would even care how much "whitespace" a tab actually is? I can't think of any situation where rustc would even need an idea of "space" a codepoint could require.
To be honest, and I don't want to sound rude, but I don't understand your point how a tab could introduce UB in rustc (or the the program you are writing). Maybe you could give an example what you mean with UB in this context so I understand?

I would also say that this is could be a problem, but most editors default to 4 or 2 spaces for tab display and I think both are "fine" (not gonna say one is better than the other as that is obviously subjective).

That's also where I used tabs a lot, and after a short while everyone around me also used them - for the sole reason that it was clearer how often you had to hit that button..

1 Like
22

No worries about sounding rude.

I did not mean to imply that use of TABs could introduce UB in rustc and the code it generated.

But given how TAB is not specified as any particular number of spaces or how that number of spaces can change across the page, it introduces undefined behavior in the final display of the source in an editor or web page or printed output etc.

I don't like that UB in display.

23

But it is defined. You define it by specifying how many equivalent spaces you want a tab to be displayed as.

1 Like
24

OK, in that way, yes.

It is defined by you, in your personal editor world for yourself.

But the meaning of TAB is not defined in Rust. As far as my google searches just now go it is not defined by Unicode either.

I consider it as being the same as tweaking the colours used for syntax highlighting in your editor. By all means configure that how you like.

As such, I don't see the problem. When your editor sees the four spaces indentation in any Rust code you happen snag from the net it can display it for you as two space indentation, or eight, or whatever you like.

25

This is the converse of the fallacy you complained about earlier:

When using TAB to align code, the correct method is to use tabs for inter-statement alignment and spaces for intra-statement alignment, as below. Blindly translating a particular number of spaces into a tab character is as incorrect as translating the tab character into a fixed number of spaces.

fn main() {
-->|while condition() {
-->|-->|do_something();
-->|-->|let foo = SomethingBuilder::new()
-->|-->|          .param_1(4)
-->|-->|          .param_2("Hello, World!")
-->|-->|          .build();
-->|-->|foo.do_something_else();
-->|}
}

FWIW, I stopped using this style years ago because it was a pain to keep up to date.

6 Likes
26

Where did that "rule" come from?

TAB does not know or care about your statements, or how many lines they span or inter/intra whatever.

Hitting the TAB key on your typewriter takes you to the next TAB stop. Wherever it may be on the line. Could be a jump of one space or ten or whatever.

Last time I used a word processor it did that as well.

Which is why all the in-house styles I have worked with outlawed TABs.

2 Likes
27

Don't you think that's somewhat backwards? It would be like if in my source code, I hard-coded every vowel to be bright orange and then told people that if they didn't like it they could configure their editor to force it to whatever they want. Yes, it's a workable solution, but it's rather absurd especially since it carries a non-zero amount of overhead.

1 Like
28

No, sorry, I don't see what you are getting at, at all.

Hard coding an attribute like "orange" to symbols in the source does sound a bit daft I admit.

But that is not what is under discussion.

Which is replacing a well defined, meaningful, symbol, the space, with a undefined symbol, the TAB.

29

I perhaps worded it too strongly, but it comes from the behavior of tab stops and the needs of formatting code. You set your editor tabstops to whatever spacing you feel comfortable with for statement indentation levels, and it preserves any ascii-art style alignment that was used to line things up within a statement.

It therefore specifies a semantic and useful distinction between tabs and spaces, which is great in theory but too expensive to maintain in practice (in my experience).

Your experience isn't the same as everyone else's, so please try to keep an open mind about differing opinions. Especially when it comes to style, which is an inherently personal thing.

4 Likes
30

Certainly everyone's experience is different. And certainly our experiences shape our opinions.

My mind is quite open enough I think. Please don't presume or insinuate it is not. On this topic I go with what "cargo fmt" does. Even if I have different ideas some times.

I do hope having different experiences, and hence opinions, does not mean we cannot express our opinions. In a light hearted "bike shedding" discussion.

1 Like
31

I personally have a strong preference towards two spaces. I think it's best when the code is sparse in terms of expression complexity (no macros, no hofs, etc) but is dense in the amount of stuff which fits on a screen.

I use two spaces for private side projects and for blogging (as good width for reading prose is petty narrow).

I wish Rust use tabs -- it is more accessible (some visually impaired folk need large tabs, or small tabls and huge font), give viewer the choice (with a major omission of profile-level config on GitHub) and easy to do correctly with industry's recent embrace of automated code formatters.

14 Likes
32

A tab is perfectly well defined, as itself - a tab - and it's semantically a very good match with code indenting, as long as 1) you use one tab per indent, and 2) you don't mix in spaces.

That second point is the only real source of grief - tabs are a fine indenting mechanism, until mixed with spaces, where they would need to be able to be defined in terms of spaces, which as pointed out isn't an option. The combination suggested above works out OK because the spaces are reliably positioned to the right of the tabs, but if it was a struggle to maintain, that isn't surprising.

33

Please remember that this thread is not about the tabs vs. spaces holy war, but two-space indentation.

3 Likes
35

One of the extra little tweaks available with Github Dark is the ability to change the tab size. It appears this is also available as a stand-alone userstyle for light theme users.

36

I use 2 spaces in all my code, after having used 4 for well over a decade. (Possibly related: I stick to a maximum width of 80 characters per line, and I don't like lines being split unless absolutely necessary). 2 spaces is enough to make it easy to glance over code and quickly see what scopes are at play, imho.

1 Like
37

One situation when rustc actually may care about that is when displaying nice and aligned error messages in the console. Sure, that's an old-fashioned way of working with a compiler, but it's still relevant (or at least enough Rust developers consider it relevant, according to the really high error message quality I see).

1 Like
38

How about a compromise? 3 spaces.
I am going to run now.

Joking aside, I find 2 a bit too narrow and 8 too wide.

1 Like
39

I love tab because it's 1 character but you can configure how long it is. It's not just a matter of principle: when I can work on a project with tabs I set it to a length 8 spaces, which is the ideal thing for me, without annoying other persons.

Talking about 2 spaces indenting specifically, I believe it excludes certain visually challenged people for a dumb matter of aesthetics.

1 Like
40

This. I've worked places that mandate tabs+spaces, and it just means that everyone needs to turn on visible whitespace in their editor and code review tools to ensure that it's tabs in the correct places and spaces in the correct places.

It's not at all worth it. People should just get over it and use whatever the convention is number of spaces. It just doesn't matter that much. (I've even worked in 3-space code, which I think is one of the worst possible choices, but whatever. I survived.)

5 Likes
41

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