A bit more detail: long ago, before the time of the Great Brace War, people wrote code using all sorts of styles: tabs/spaces, short or long variable/function names, Hungarian notation or not, comments or not, long blocks or short, and so on. You could often tell which of your teammates wrote a block of code simply by newline usage. This made it hard to read and contribute code in a less familiar part of the codebase.
Google mitigated this problem at scale by introducing the concept of "readability" for each language (C++, Java, and Python, simpler times). If you had readability, you could approve another person's change for that language. If you didn't, you could still review the code, but the reviewee also had to go find someone else with readability.
After you'd accumulated a certain number of commits in a language, you could try to get your own readability by bundling up your CLs (changelists) and submitting them to the readability queue, where a certain group of senior people with readability would evaluate whether your code was sufficiently idiomatic. This process could take months, or even years if you didn't write much in a particular language. In any event, it felt like a real achievement to get readability.
The upshot of all this was that most code at Google felt authorless in a good way: if you knew and expected Google style, all the codebase felt the same, and you could concentrate on the logic flow rather than the regional dialect. And needless to say all the energy wasted on whose style was best was squelched in the readability queue.
This is all past tense because I last wrote code for Google more than 10 years ago, and I'm sure the process has changed since then. Code formatters, shared editor defaults, and presubmit checks have surely automated away a lot of the toil, and there's much less of a monorepo culture these days, so there are probably more style dialects (in addition to many, many more permitted languages).
1) go kinda eliminates a lot of the reasons for style guides to exist w/ `go fmt` and separately, I think the Go readability team made a conscious decision to approach readability differently anyway,
2) ... once you had a couple people on your local team w/ readability, if your team wanted to do things a certain way, well, style guides and formal readability wasn't really an issue anymore.
I was wondering if someone was going to ask. It's the most bizzare aspect of code reviews at Google.
And "Readability" doesn't mean you are good at a language, it means you are good at it in the way Google uses it. C++ readability is the poster child of this. Borgcron, not so much.
It is a formal process via which it is confirmed that you know enough of X to submit code to the codebase, where X can be c++, java, python, etc. If you don't have X readability, then, in addition to your main code reviewer, you need to have a readability reviewer look at your code, who will be focusing only on X, not the logic of your code.
readability grants a code reviewer the power to approve changes in a specific language
A bit more detail: long ago, before the time of the Great Brace War, people wrote code using all sorts of styles: tabs/spaces, short or long variable/function names, Hungarian notation or not, comments or not, long blocks or short, and so on. You could often tell which of your teammates wrote a block of code simply by newline usage. This made it hard to read and contribute code in a less familiar part of the codebase.
Google mitigated this problem at scale by introducing the concept of "readability" for each language (C++, Java, and Python, simpler times). If you had readability, you could approve another person's change for that language. If you didn't, you could still review the code, but the reviewee also had to go find someone else with readability.
After you'd accumulated a certain number of commits in a language, you could try to get your own readability by bundling up your CLs (changelists) and submitting them to the readability queue, where a certain group of senior people with readability would evaluate whether your code was sufficiently idiomatic. This process could take months, or even years if you didn't write much in a particular language. In any event, it felt like a real achievement to get readability.
The upshot of all this was that most code at Google felt authorless in a good way: if you knew and expected Google style, all the codebase felt the same, and you could concentrate on the logic flow rather than the regional dialect. And needless to say all the energy wasted on whose style was best was squelched in the readability queue.
This is all past tense because I last wrote code for Google more than 10 years ago, and I'm sure the process has changed since then. Code formatters, shared editor defaults, and presubmit checks have surely automated away a lot of the toil, and there's much less of a monorepo culture these days, so there are probably more style dialects (in addition to many, many more permitted languages).
I left in 2023. From memory at that time:
1) go kinda eliminates a lot of the reasons for style guides to exist w/ `go fmt` and separately, I think the Go readability team made a conscious decision to approach readability differently anyway,
2) ... once you had a couple people on your local team w/ readability, if your team wanted to do things a certain way, well, style guides and formal readability wasn't really an issue anymore.
I was wondering if someone was going to ask. It's the most bizzare aspect of code reviews at Google.
And "Readability" doesn't mean you are good at a language, it means you are good at it in the way Google uses it. C++ readability is the poster child of this. Borgcron, not so much.
Did you mean Borgmon? Borgcron is just GCL.
Sawzall is another good example of an unreadable language.
It is a formal process via which it is confirmed that you know enough of X to submit code to the codebase, where X can be c++, java, python, etc. If you don't have X readability, then, in addition to your main code reviewer, you need to have a readability reviewer look at your code, who will be focusing only on X, not the logic of your code.