Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
I am in love with this awsome document; I love its guidelines, and coding conventions.
However, when Rust was introduced into the kernel, they butchered these beautiful guidelines, I know it’s hard to look at such heretic actions, but you have to see this:
The default settings of
rustfmtare used. This means the idiomatic Rust style is followed. For instance, 4 spaces are used for indentation rather than tabs.
How can this even relate to the ideology of the first document? I am deeply saddened by these new rules.
I know this is “The Rust experiment”, but this must be fixed before it’s too late! This has to reach someone.
A counter-argument might be:
The code should be formatted using
rustfmt. In this way, a person contributing from time to time to the kernel does not need to learn and remember one more style guide. More importantly, reviewers and maintainers do not need to spend time pointing out style issues anymore, and thus less patch roundtrips may be needed to land a change.
And to that I say that rustfmt is configurable per project, and if it isn’t, then it has to be. Doesn’t something like .editorconfig exist?
Edit: I think I read enough comments to come up with a conclusion.
At first, forcing another language’s code style upon another sounds backwards, but both styles are actually more similar than I originally though, the kernel’s C style is just rustfmt’s default with:
- 80 character line.
- 8-space hard tabs.
- Indentation limited to 3.
- Short local-variable names.
- Having function length scale negatively with complexity.
The part about switch statements doesn’t apply as Rust replaced them with match.*
The part about function brackets on new lines doesn’t apply because Rust does have nested functions.
The bad part about bracket-less if statements doesn’t apply as Rust doesn’t support such anti-features.
The part about editor cruft is probably solved in this day & age.
The rest are either forced by the borrow checker, made obsolete by the great type system, or are just C exclusive issues that are unique to C.
I left out some parts of the standard that I do not understand.
This all turned up to be an indentation and line-size argument. Embarrassing!
*: I experimented with not-indenting the arms of the root match expression, it’s surprisingly very good for simple match expressions, and feels very much like a switch, though I am not confident in recommending to people. Example:
match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
Ok(_) => foo2(),
Err(e) => match maybe(e) {
Ok(_) => bar2(),
_ => panic!(),
}
}
_ => panic!(),
}
honestly 8 space indents always felt a bit ridiculous to me. i usually use 4 since it’s more conventional in most languages but could also be happy with 2.
weird hill to die on. use default setting unless you have a good reason not to. the argument itself is a waste of time on projects that want to get things done.
Also to advocate for a specific tab size while also advocating for hard tabs is nonsense. The one flimsy claim to usefulness tabs have is that different people can use different tab sizes and all at the low, low cost of everyone having five times more work to use tabs for indentations and spaces for alignment and thus having to use visual whitespace of some kind.
having five times more work to use tabs for indentations and spaces for alignment and thus having to use visual whitespace of some kind.
Excuse me. What does that mean? (also see my reply to 1rre)
What they’re referring to is that when you use tabs, you end up having some things at the end of lines have to be spaced over for alignment. Thus, you then have to turn on some way of seeing what stuff is tabs and what stuff is spaces and it turns into a big mess.
Hence why normal people indent with spaces instead of hard tabs
So, why don’t people just restrict tabs to pre-text, strictly-sized indentation?
On a side note: I think (not sure) that indenting with 8 or more spaces just to align 2 similar but differently sized lines of code is a bit too much.
afaik it’s like that to discourage heavily nested code but don’t quote me on that
My biggest disagreement is this:
Do not unnecessarily use braces where a single statement will do.
Always put braces around if statements. It will bite you in the butt
I would go so far as to say that languages that allow you to leave off the braces and have macros that look like functions that can generate multiple statements at the same time are just plain badly designed.
Thank god macros and functions are different colors in my IDE.
This one in particular I am against. (it’s not like it’s possible in rust anyway)
Rustfmt is not very configurable. That is a wonderful thing: People don’t waste time on discussing different formatting options and every bit of rust code looks pretty identical.
My emotions just stopped, so I can now think straight.
There are really only 2 changes that - in my eyes - should be made:
- 8 space-long, hard tabs.
- 80 character limit instead of 100.
I don’t think a tool like
rustfmtcan affect most of the original guidelines, and it’s generally compatible with the OG style by default.Edit: I - surprisingly - never actually used
rustfmt, so I will go now and test before I say something stupid.Edit II: I just found this on their repo:
Rustfmt is designed to be very configurable.
Edit III: I tested
rustfmtwith:hard_tabs = true
max_width = 80
It’s great!
We are not stuck to DEC VT100 terminals anymore. It’s okay to have 100 columns of code. And wasting 10% of that space for each indentation? What are you smoking?
wasting 10% of that space for each indentation? What are you smoking?
As I said before, this standard is older than C itself, and the kernel’s been using it for decades, I shouldn’t have to explain it. Long tabs and short lines boost readability, and restricting indentation to 3 solves the problem. Read my reply to 1rre@discuss.tchncs.de for more context.
Also
rustfmtdidn’t move the string inprintln!("a very long string slice with a static lifetime");to a new line even when it exceeded a 100 columns, I should seek a solution.Note: The actual string I used was way longer than that.
8 space-long, hard tabs.
Hard disagree. 8 spaces is waste and 4 should be industry standard. Tabs should not be used for indentation, but spaces. On the other side, Tabs are configurable, so that’s actually a plus point.
80 character limit instead of 100.
Why? 80 is an old standard with limitations that do not apply today anymore. We have wider screens and higher resolutions. While it makes sense to keep this to be consistent with previous code and language defaults for C, there is no reason to enforce this for the new adopted language, which already has a standard on its own.
And yes rustfmt can be configured and when I started with Rust I changed max_width to 80, just because I was used to it with Python. But there is no benefit doing this in Rust.
80 character limit instead of 100.
8 space-long, hard tabs
Either you use hard tabs, which you happen to have configured to 8 spaces locally because you’re some sort of masochist, or, if you’re more of a sadist, you use 8 spaces in place or tabs. One of the great things about using hard tabs is that people can configure them to be whatever size they want; 2, 3, or 4 spaces, so specifying a size in your style guide is redundant as they’ll just appear as the pre-configured size to anyone else. The only reason to specify hard tab size is if your style guide is satirical or esoteric, which I guess if you’re specifying 8 spaces it certainly is anyway.
80 character limit is kind of reasonable, but I think the intersection between people who have a low resolution, narrow aspect ratio screen and people who code in rust is significantly lower than C or C++, and it’s unlikely they’ll want a 3-way vertical split in a terminal/editor, so a 100 or even 120 column limit makes more sense in my opinion especially given it doesn’t require editing code that’s already written, but I wouldn’t argue against enforcing 80 for consistency
But how else are you going to enforce a specific line size?(I remembered formatters exist, don’t mind this)I was thinking of something else, something better, but I do not know if it exists, I’ll say it:
The thing I don’t like about space indentation is how you can individually delete and select each space while editing, which is aesthetically unpleasing and error prone, which makes a formatter necessary. Using spaces is also weird in the sense that indentation is supposed to be a block of continuous whitespace, not little things joined together.
However, using tabs creates inconsistent results when copying code to a browser or online view in general.
My idea is: configure your editor - ideally through
.editorconfig- to interpret 8 continuous spaces as a tab, and display them as such, and when the time comes to save, you tabs are actually saved as 8 spaces, which solves both the aesthetics and portability problem.Is this possible? does this already exist? I do not know.
Edit: I forgot your second paragraph
Maybe it’s because I use 18.5 inches and 1366x768*, but an 80 character long line already makes me shift my eyes in a way I prefer not to. Low line length is just comfortable.
It’s worth mentioning that I recently increased my coding font size to Neovide’s default (from 12 -> 14), which made me realize why people do things like
Ok(()), sticking parentheses look weird on low font sizes.I believe that limiting indentation - to 3 - makes code better, an opinion I based on the Linux guide and a video with good animations.
*: I only needed to fix it once in the last 10-14 years; I don’t remember anymore. Why change what’s working? it’ll only make playing video games awkward needing to pipe everything through Wine’s FSR.
Speaking of that one repair job, the repairman just replaced all of the monitor’s insides with another model’s, and now I cant tweak brightness or contrast or use anything but auto adjustment.
which you happen to have configured to 8 spaces locally because you’re some sort of masochis
Edit II:
which you happen to have configured to 8 spaces locally because you’re some sort of masochis
8 space tabs have been the default since the K&R days.
Tabs being 8 spaces has been the norm since the typewriter (actually not)
Despite the fact that five characters were the typical paragraph indentation on typewriters at that time, the horizontal tab size of eight evolved because as a power of two it was easier to calculate with the limited digital electronics available.[citation needed]
Why do people hate them that much nowadays?
Edit III:
I think the intersection between people who have a low resolution, narrow aspect ratio screen and people who code in rust is significantly lower than C or C++
Maybe you’re right, I should ignore the sunk cost of reading a 3rd of The Rust Programming Language book, and leave Rust to the cool new generation with their HD displays, and non-DIYed setups)**, and social media usage, and their computers are fast so just write it in javascript and forget about older systems and 3rd world countries and the poor and environment hurting emmisions, and just go learn C. I always felt like I fitted in with people 1 or 2 generations older. (I am not actually going to do that, that’s a joke)
**: BTW, my speaker’s left channel is an old radio that is connected to my speaker’s cable. My left speaker broke when I pushed it off the table, served for a good 8-12 years; I still don’t remember anymore.
I think they can just ban tabs. And do some automatic rejection via… what? Are kernel devs still using email attachment for this?
You are just stoking the flames of a meaningless holy war.
The kernel had a consistent style before rust was even an idea! Who do you think has started this inconsistency? (Maybe not, what does someone like me know about the kernel anyway)
Not a lot, apparently.
Agreed, and upvoted.
To be fair, consistent styling across the entire project is not meaningless. But on the other side, I don’t think this needs to be fixed here, because it is already consistent (within their language).
How can this even relate to the ideology of the first document? I am deeply saddened by these new rules.
The previous document was written in a time when only C was the language in the Kernel. Now that two different languages and eco systems exist, it makes lot of sense to not mix them up. The document with guidelines for C code was needed, because there was no uniform guide that every user used. But with Rust it is different. There exist rustfmt and practically every user is learning and writing code with it and every public documentation and library is using this tool; most of them with default values.
You don’t mix C with Rust anyway, so why do you want force every Rust programmer and code formatted like C? I don’t think this is an issue that needs to be fixed. Are you programming for the Linux Kernel? Do you do it in C and Rust? Otherwise, why do you think this is a problem?
Edit: Also the very first paragraph and second sentence in the linked document says this:
Coding style is very personal, and I won’t force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I’d prefer it for most other things too.
But you seem to ignore that and force everyone to write code like this, declaring it to be an issue in the code (which it isn’t). Do you not think that other Linux developers didn’t think of this? Why is this an issue that has to be fixed and how do you explain this? Why does the C coding standard apply to Rust, when Rust has its own established one?
Is this a joke?
Obviously, 8 wide tabs are too much. That’s like defining Pi as 5.
No, it is not, people have been using 8-space tabs even back when terminals were limited to 80 characters.
Yeah, sometimes people make mistakes but we can change for the better.
Personally, I wish everyone would just use the tab character and configure how it gets displayed in their editor, instead of imposing spacing on everyone
Finally, something is beating python in how ridiculous it is. Yay!
deleted by creator
Agreed not tabs
8 spaces seems excessive.
4 spaces or even 2 would be my preference.
Disclaimer: lots of programming but no rust experience. Though, I don’t think that matters.
First saying that tabs are a no go, then proceeding to deliberate on the correct amount of spaces…
Long live tabs!
What happens when the defaults change? Is old code all of a sudden not following the style guidelines?
Yes.
Silicon Valley vibes (the series).
Doesn’t the kernel have a coding standard?
It has a long-lasting
Ccoding standard, they call it the standard since it was the only language anyway. Then, they made a newly conceived Rust standards, which ignore everything the original standard stood for. (Note the strong language in the post’s first quote, it’s from the original standard)Why should we have the same standard for two fundamentally different languages with distinct design philosophies and features?
Even if the C coding standard was used, it fundamentally will not make Rust more legible to C-only kernel devs. Imposing the C coding standard on Rust would be fundamentally counterproductive, as it would undermine Rust’s safety and productivity features. Rust’s coding guidelines align with its design principles, promoting idiomatic Rust code that leverages language features like ownership, borrowing, and lifetimes.
This ensures that Rust code in the kernel is safe, concurrent, and maintainable, while adhering to the language’s best practices. While the C coding standard served its purpose well for the procedural C language, it is ill-suited for a modern language like Rust, which has different priorities and language constructs. Having separate coding standards allows each language to shine in its respective domain within the kernel, leveraging their strengths while adhering to their respective design philosophies. Having separate coding standards for C and Rust within the kernel codebase is the sensible approach.Well, what I meant was just
rustfmt’s default with:- 80 character line
- 8-space hard tabs
In addition to naming local variables short names, and soft-limiting functions to 48 lines long & their local variables to 5-10 (you know, normal reasonable things)
The part about
switchstatements doesn’t apply as Rust replaced them withmatch.*The part about function brackets on new lines doesn’t apply because Rust does have nested functions.
The bad part about bracket-less
ifstatements doesn’t apply as Rust doesn’t support such anti-features.The part about editor cruft is probably solved in this day & age.
The rest are either forced by the borrow checker, made obsolete by the great type system, or are just
Cexclusive issues that are unique toC.I left out some parts of the standard that I do not understand.
I just skimmed through the Rust style guide, and realized the only real difference between the 2 standards is indentation, and line length. Embarrassing.
*: I experimented with not-indenting the arms of the root
matchexpression, it’s surprisingly very good for simplematchexpressions, and feels very much like aswitch, though I am not confident in recommending to people.Edit: How did I forget?! Indentation is limited to 3, increasing code readability.
