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
rustfmt
are 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!(),
}
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:
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?