Hi, I was check on the google before ask to this forum. Some source told me that TAB is like jumping and space is about space (different character too).
I use VS code and make an experiment. Tab/space is same. Because the indent stopped on same letter. Thanks....
You can use either spaces or tabs in your Rust code.
However, the default settings for the standard Rust code formatting tool rustfmt will convert tabs into spaces when re-formatting your code. Presumably VS Code is set up to use rustfmt on your Rust files. If you wish to use tabs, you can reconfigure rustfmt to do so (see the documentation).
You can read a discussion about spaces vs tabs in Rust code here:
Edit: It appears VS Code converts tabs to spaces automatically by default, regardless of whether you use rustfmt.
VS Code lets you control text indentation and whether you'd like to use spaces or tab stops. By default, VS Code inserts spaces and uses 4 spaces per Tab key. If you'd like to use another default, you can modify the
editor.insertSpacesandeditor.tabSizesettings.
You don't have to. Rust doesn't care about indentation like Python does, say; where whitespace is required, any whitespace will do. You don't even have to indent at all.
What rustfmt, your editor, and your colleagues impose is another matter. VS Code is probably interpreting your inputs to make things consistent.
More generally than Rust, "tabs vs spaces" is a never-dying holy war; just do an internet search to find endless articles and rants on the topic.
This is one reason why I think that rustfmt, gofmt etc are so useful: not because of their immediate formatting function (although that is of course useful too), but because it just settles such useless debates by biasing the entire ecosystem toward one or the other.
This is also why OP shouldn't use tabs: not because it can't be done, but because their project will be one of the handful, vs the literal thousands of extant Rust projects. And if they ever accept commits from others, that will be an additional source of friction.
Regardless of one's preference for tabs or spaces (again, a superlatively useless debate if you ask me, to the point that the comedy series Silicon Valley actually satirized this), going against the ecosystem norms is generally a bad idea, and makes life harder for all involved.
The main argument for using tabs for indentation is accessibility. The ability to distinguish indentation space from word separator space makes life easier for people who need assistive technologies or simply different indentation levels to read code.
I have no experience with accessibility technologies in that context, so I'll assume that's true.
The solution then, for people in need of accessibility, is to alter the way those indentation spaces are rendered to the person in question by various utilities.
That is, it's a (collection of) purely local setting(s), and it should be 100% invisible to the outside world.
That yields the best of both worlds: the person in question gets the accessibility feature(s) they need, without causing friction, or having to deal with that friction themselves.
I wonder how valid that accessibility argument is? Do we have any blind programmers here who can comment on that? I ask because I have met blind programmers and none of them brought up any issue with indentation, spaces vs tabs. Also, at least in theory, those indentation and spaces/tabs have no meaning, the compiler is blind to them. It's a different matter with crazy syntax like Python though.
Thanks for the answer all!!
This should not be a problem, because VSCode automatically detects indentation when opening a file, and because contributors should always run fmt before committing.
Except there will be developers that are not using VSCode and do not run fmt before committing. Then we end up with a lot of white space changes in git diffs. Which is really annoying.
Most modern IDEs are capable of automatically detecting indent style and width. In my experience, the cases where they guess incorrectly are vanishingly small. Tabs and spaces as indentation are treated practically the same these days[1], including keyboard navigation and rendering.
It's only "dumb text editors" like notepad that aren't capable of hiding the distinction.
This also suggest that "tabs are better for accessibility" is not necessarily a strong argument. ↩︎
it is easier to just TAB than to hit spacebar 4 times.
thats for me.
That is great. As long as hitting TAB inserts four spaces 
Just want to point out that lots of people in the community are perfectly fine when other need or want to use formatting options.
Higher volume in discussions doesn't make opinions more valid.
I'm saying this because this thread seems resolved, but seems to be in the mode where it keeps running until everybody that's left has the majority opinion.
That is all.
I agree. The thread has a solution, and there seems to be little left to discuss. I'll decrease the topic timer[1] so the discussion can come to an end soon
that determines how long after the last reply the topic auto-closes ↩︎
As far as I know, the strongest argument for tabs is provided by Elastic Tabstops. And this is the strongest argument against that. However, it's not entirely clear whether the performance really can't be improved, because no one has put that much effort into optimization.
Anyway, I think the big picture of spaces vs. tabs is often muddled because its scope is arbitrarily limited. For some, it might be insightful to take them into their respective logical conclusion.
The "spaces camp" values the simplicity of plain text. They like having this grid of cells they can draw things on with glyphs[1], which are laid out equally for everyone. The contents of the grid are then parsed into AST by the programming language of their choice, or transformed isomorphically by the formatter of their choice. To this end, things like syntax highlighting, type hint, indentation marker, ligature, etc. are not the first-class features of the code.
The "tabs camp" values the extensibility of rich text. They like parsing code style features like indentations and brackets as markups, of which style is determined by project and editor configuration, like how HTML style is determined by CSS and browser. This separation of style and structure, done consistently, would leave nothing for the formatter to do.
Both options have their own upsides and downsides. Plain text is easier to develop tooling for, and it can be sent anywhere without causing compatibility problems. Rich text, on the other hand, can better adjust to different people with their different visual preferences.
For now, the "spaces camp" have successfully captured the "don't care camp" by the virtue of requiring less editor configuration. Meanwhile, the "tabs camp" have struggled for the same reason XML did. Even though the expressive power of rich text is useful in some specific contexts, the amount of upfront and continuous investment required has made it unattractive to most people. Ultimately, the situation was not about which paradigm would result in a higher productivity, but rather "perfect is the enemy of good".
At least within ASCII. Even the code-oriented monospaced fonts are usually not monospaced across all of Unicode. ↩︎
If you are using a decent editor (you don't even need an IDE, just a real text editor that's not Notepad), it will autoindent for you and respect tab stops, even if there are literal spaces in the source code.
"How many keys I hit" is not something we need to (or should) optimize for.
Wow I like this idea.
Algorithmically speaking, it's rather easy to make it performant -- you just need to store the elastic tab positions in an appropriate data structure rather than recompute everything from scratch on every keystroke. The comment on the ticket also says as much, they just think it would be "insanely hard to keep consistent and add a huge maintainance burden", but I don't think that's really true.
This topic was automatically closed 12 hours after the last reply. We invite you to open a new topic if you have further questions or comments.