Rust Style Guide

Apply #[non_exhaustive] to publicly-exposed enums seems like a crazy recommendation to me. So much of the power of enums is that when you add a new case the compiler will flag all pattern matches that you need to update, which is a good thing because you're forced to consider each case. Having a catch-all saves dev-time but it risks not appropriately handling new cases becoming a runtime issue instead of a compile time error.

Can anyone expand on the chromium specifc guidelines on super tiny crates, particularly no nesting of modules/source files?

That feels like the ~2010 era of people saying that functions should be as small as possible. That lead me to reviewing a lot of code where every function was one or two lines and you couldn't actually see what was going on anymore through the layers of unneeded abstraction.

I want to give chrome the benefit of the doubt, but that seems really goofy.

> Type names should be imported and used unqualified

This just pushes people to have redundant information in types (`IoError` instead of `io::Error`).

Unless a type is widely recognized (like `HashMap`), I prefer to have them fully qualified so I have the contextual meaning for it. If I am working with a generic name like `Source`, what does that mean? I shouldn't have to look up in the imports to understand the code (or only understand it through an LSP).

Reducing imports also reduces unnecessary merge conflicts.

Google has lost a lot of it's sheen for me. It's not really the 2010s anymore where their brand really used to mean something as a step above all the other tech companies.

Nowadays, I care about their recommendations as much as the ones from microsoft, or ibm.

Still big companies, lots of smart people, but nothing above norm.

Here's a tip most Rust users don't know about extension traits: if you put `#[rust_analyzer::prefer_underscore_import]` above your trait (and you're using rust-analyzer and not RustRover), autocompletion and the import assist will import the trait `as _` by default, which is very useful for extension traits.

This is nice, I have been lurking on google and meta rust projects, mimicking and picking style by prompting LLMs to distill it, taking a look at fmt & clippy configs helps too.

But it wasn't as coherent and reliable from project to project like this guide. Kudos to google on this one !

Much of this is very standard across the Rust ecosystem but it's very helpful to have it all in one place.

At this point, is anybody writing new C or C++? It seems like they are sunset languages even at the big corps.

I really appreciate that they distinguish between library code and application code. Rust gets too much of a bad rap for its complicated generic code, but in most application scenarios you are not writing code nearly that complex or generic.

The enum-over-bool rule is the one I'd keep even solo, saved me a reversed flag in a cert validator once.

> Don’t use async / .await in Chromium.

That's pretty direct. IIRC, the Rust for Linux people also have that refrain informally

Getters and setters is the one I'm most at disagreement with.

   // Mine
   let label = Label.text("Hello Wold");
   let label_text = label.get_text();

   // Theirs
   let label = Label.set_text("Hello Wold");
   let label_text = label.text();

A method is a way to accomplish a specific task. Emphasis on specific not generic. The getter task is to always return. The setter task is specific. So the method should be the setter - `text`, `color`, `fill`. In Rust the getter can't have same name, so prefix it. Not the other way around.

I have a huge disagreement here. You should absolutely be using Arc and Rc for any references *that live outside of the call stack.*

Don't do weird crap with lifetimes to try and convince the compiler that what you're doing is ok, just throw Rc/Arc on it and be done with it.

The Rc/Arc advice also applies to C++ IMO, though you use different constructs, std::shared obviously, but there is a strong argument to be made for a std::shared_st or something which is single threaded.

It would not surprise me if this advice comes from experience with C++ where there is no Rc so reference counting is very expensive. Even so, you can greatly reduce the expense by passing things by ref where lifetimes are simple which is the vast majority of the time.

How useful would this be to simply feed to an LLM and say to follow strictly?

> Usage of lowercase alphabets in hex literals (0xab123cdef as opposed to 0xAB123CDEF): hex_literal_case = Lower

Anytime numbers and letters are mixed, it's more readable if the letters are lowercase. It's easier to read the variable heights - numbers are usually capital letter height, sometimes with descenders - and avoids confusing 0O, I1, even 8B and 5S (think of a degraded printed serial number, poor lighting, etc.). There's only l problem that persists.

[flagged]

ctrl+c > ctrl+v > into my AGENTS.md for my next rust project /s

[flagged]

why is google using github, a Micro$oft product?

Things like this make me appreciate Gofmt so much

Not trying to rain on someone's parade but, the only reason why would care about style guides nowadays is to feed them to our model of choice and let it do what it's supposed to be doing.

So it's not like I am willing to read through this and think to myself "I cannot wait to pick up some new ways of doing things". I'm the general to my agentic army now.

I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?