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!(),
}

    • Doods@infosec.pubOP
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      It has a long-lasting C coding 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)

      • Rustmilian@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        8 months ago

        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.

        • Doods@infosec.pubOP
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          edit-2
          8 months ago

          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 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.

          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 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.

          Edit: How did I forget?! Indentation is limited to 3, increasing code readability.

  • Tobias Hunger@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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.

    • Doods@infosec.pubOP
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      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 rustfmt can 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 rustfmt with:

      hard_tabs = true

      max_width = 80

      It’s great!

      • acockworkorange@mander.xyz
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        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?

        • Doods@infosec.pubOP
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          edit-2
          8 months ago

          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 rustfmt didn’t move the string in

          println!("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.

  • chrash0@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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.

    • taladar@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      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.

      • Doods@infosec.pubOP
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        edit-2
        8 months ago

        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)

        • KindaABigDyl@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          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

          • Doods@infosec.pubOP
            link
            fedilink
            arrow-up
            0
            arrow-down
            1
            ·
            edit-2
            8 months ago

            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.

  • KindaABigDyl@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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

    • Doods@infosec.pubOP
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      edit-2
      8 months ago

      This one in particular I am against. (it’s not like it’s possible in rust anyway)