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.

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

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

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

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

no amount of stylistic heterogeneity can make this awful language pleasant

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?