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 !
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.
Maybe one or two line functions are a totally different scale than "all source code files in a crate"? So like, one is problematic in a way the other is not. And the guidance is "prefer small," not "always super tiny."
I'm pretty sure most big software projects (Windows, Linux, Chrome, clang, gcc, ...) are still writing a lot of new C and C++. Pretty much everyone in the embedded world as well.
As a solo programmer, I still prefer C and C++. In fact, as I've adopted LLMs more, I've been increasingly drawn toward C and its simplicity.
Are you just being snarky, or do you have something more specific to say about something that's choosing C?
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
C++ seems alive and well in the defense space. The big contractors near me have tons of C++ job postings and I don't think I've seen a single one looking for Rust.
This is a sub-case of the general one that is narrowing the interpretation of things. A big infinite amount of things can be true or false, only one can be a Rust variant.
The good emotions come with the confidence in the engineering quality that it gives you as output (once you overcome the friction, which AI can help you big time to achieve).
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?
I'm not sure I really agree with your main point (I think it's probably still important for LLM-generated code to be generally human-understandable, at least if you care about long-term maintainability), but setting that aside to answer this question:
> 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?
I think they're still quite valuable in that case, for a couple reasons:
- When learning a new language (which happens much more frequently when writing code "for pleasure," as it were), "written for scale" guidelines still translate pretty well to "written for oneself" IME. At the very least, they tell you what to expect in code you read, and give you a reasonable starting point as you develop your own taste and stylistic preferences.
- I've noticed some open source projects beginning to institute anti-AI contribution guidelines, and such projects still benefit from codified style guides. Google obviously doesn't fall under this category themselves, but in other language ecosystems, their style guides tend to find use in OSS projects.
First paragraph: “includes guidance on API and implementation design”
It seems to me that if the intent is not just to produce code but also to operate it, having the different pieces behave in a similar, predictable way is kind of nice. Whether the software is written by AI or humans.
This is what we do in my company, give the guidelines to the model. Unfortunately, the model isn't always following them and it's impossible to enforce them manually. There's too much code to review, the code is generally low quality, and is more often than not auto-approved by AI.
Unless you're working on your own project on which you have full control, or you have a strong authority figure in your company who cares about that, it's a lost battle.
It's sad for anyone who love their craft, but tbh I'm not even sure it matters anymore for most projects.
The point of style guides is to optimize for readability despite a cognitively diverse workforce coding in the same repos.
I would think they're probably even more meaningful in an agentic world.
Shitty generals can't review meaningfully review the work of their troops.
On top of that all, I just enjoy programming itself. It's less and less of the meat of a software job over time, but I was coding before I got paid for it, and I'll probably keep coding well after I can get paid for it.
Not trying to rain on someone's parade, but the only reason I would care about HN comments nowadays is to feed them to my model of choice and let it generate the contrarian hot takes it's supposed to be generating. So it's not like I am willing to read through this thread and think to myself "I cannot wait to pick up some new ways of complaining about documentation." I'm the Editor-in-Chief to my synthetic pundit army now.
I guess you would type out a comment manually every now and then for your own enjoyment, but at that point do you really care about comments at scale?
---
EDIT (above is a joke) It's very important that every time you find something that is of no use to you, you write a comment explaining that this link is of no interest to you, discouraging people from things you have no interest in. Monoculture for all!
But it wasn't as coherent and reliable from project to project like this guide. Kudos to google on this one !
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.
As a solo programmer, I still prefer C and C++. In fact, as I've adopted LLMs more, I've been increasingly drawn toward C and its simplicity.
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
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?
> 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?
I think they're still quite valuable in that case, for a couple reasons:
- When learning a new language (which happens much more frequently when writing code "for pleasure," as it were), "written for scale" guidelines still translate pretty well to "written for oneself" IME. At the very least, they tell you what to expect in code you read, and give you a reasonable starting point as you develop your own taste and stylistic preferences.
- I've noticed some open source projects beginning to institute anti-AI contribution guidelines, and such projects still benefit from codified style guides. Google obviously doesn't fall under this category themselves, but in other language ecosystems, their style guides tend to find use in OSS projects.
It seems to me that if the intent is not just to produce code but also to operate it, having the different pieces behave in a similar, predictable way is kind of nice. Whether the software is written by AI or humans.
Unless you're working on your own project on which you have full control, or you have a strong authority figure in your company who cares about that, it's a lost battle.
It's sad for anyone who love their craft, but tbh I'm not even sure it matters anymore for most projects.
What have you produced with your agentic army? Would you like to share with the class?
I would think they're probably even more meaningful in an agentic world.
Shitty generals can't review meaningfully review the work of their troops.
On top of that all, I just enjoy programming itself. It's less and less of the meat of a software job over time, but I was coding before I got paid for it, and I'll probably keep coding well after I can get paid for it.
I guess you would type out a comment manually every now and then for your own enjoyment, but at that point do you really care about comments at scale?
---
EDIT (above is a joke) It's very important that every time you find something that is of no use to you, you write a comment explaining that this link is of no interest to you, discouraging people from things you have no interest in. Monoculture for all!