[sgeisenh]

Google places a pretty high emphasis on code quality and readability. It's not universally great, but it's a big part of the culture. You can catch a glimpse in their [style guides][1], [abseil totws][2] and [aips][3]. Almost every change is required to be reviewed for "readability" in addition to functionality. This can feel like a lot, but it leads to pretty consistent style across the codebase which makes it a lot easier to switch projects or read and understand an unfamiliar section of the code.

[1]: https://google.github.io/styleguide/ [2]: https://abseil.io/tips/ [3]: https://google.aip.dev/

[CharlieDigital]

I find Google's take on code reviews to be particularly good:

https://cloud.google.com/architecture/devops/devops-tech-tru...

[ok_dad]

I enjoy how they state like 3 times that code reviews should be synchronous, yet "industry-standard" (aka: what people really do) is to toss it over the fence in a PR and go back and forth for several days with stylistic bullshit.

[Jensson]

Code reviews are usually synchronous at Google though, commenting and fixing things is like chatting with the reviewer so are usually done quickly. Not sure why this wouldn't be industry standard, is there any reason to make code reviews more painful than that?

[ok_dad]

I was kinda joking that places like Google might have good processes but most places just cargo cult it and do it incorrectly. My current job does reviews that are so useless I don’t even participate anymore and no one cares. I really want to work at a place where they care about code quality and an effective process.

[aftbit]

Oh, Abseil is new to me. Thanks!

Do you know where the missing tips are? For example:

https://abseil.io/tips/110

The root page (parent's [2]) mentions this one as famous by name:

>Often they are cited by number, and some have become known simply as “totw/110” or “totw/77”.

Is totw/110 some Google secret sauce that we are forbidden from knowing or did they skip some weeks?

[joshuamorton]

A lot of them are related to Google-internal practices or libraries, or are like too opinionated (Google has strong internal C++ opinions that aren't necessarily correct or even reasonable elsewhere) to be useful.

110 in particular probably could be public, but it looks like they stopped externalizing them in late 2020, which is kind of sad, so I assume they never got around to it.

[jrockway]

Yeah, that sounds about right to me. I used to help edit Testing on the Toilet and there were a lot of internal-tool-specific ones that we never made public. When we were low on content, we would happily publish an issue about someone's internal service/project, for example. It's not that we were trying to hide something, it would just be completely useless to the outside world.

[Thorrez]

TIL TotT is externalized.

https://testing.googleblog.com/

[kccqzy]

I asked a Google friend to find totw/110 for me and apparently it's just some tips about construction and destruction of global variables.

[iamstupidsimple]

These missing TotW's are usually about internal tools that aren't open source.

[skirmish]

totw/110 was about safely initializing global and static objects. IIUC there was something missing in the open sourced version of Abseil so that it could not be published verbatim.