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.
show comments
incrediblers
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.
show comments
epage
> 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.
show comments
preommr
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.
JoeDohn
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 !
tcallred
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.
i2talics
Much of this is very standard across the Rust ecosystem but it's very helpful to have it all in one place.
petcat
At this point, is anybody writing new C or C++? It seems like they are sunset languages even at the big corps.
show comments
oddCopper65
The enum-over-bool rule is the one I'd keep even solo, saved me a reversed flag in a cert validator once.
show comments
slaymaker1907
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.
show comments
mmooss
> Usage of lowercase alphabets in hex literals (0xab123cdef as opposed to 0xAB123CDEF): hex_literal_case = Lower
Anytime numbers and letters are mixed, the letters should be 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.
younglunaman
ctrl+c > ctrl+v > into my AGENTS.md for my next rust project /s
icase
no amount of stylistic heterogeneity can make this awful language pleasant
show comments
holografix
Things like this make me appreciate Gofmt so much
Thanemate
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?
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.
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.> 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.
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 !
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.
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.
The enum-over-bool rule is the one I'd keep even solo, saved me a reversed flag in a cert validator once.
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.
> Usage of lowercase alphabets in hex literals (0xab123cdef as opposed to 0xAB123CDEF): hex_literal_case = Lower
Anytime numbers and letters are mixed, the letters should be 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.
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
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?