Yes. This is part of the no long lived branches[0] culture. Fwiw, I have found it superior to having to do huge merges.

[0] https://dl.acm.org/doi/10.1145/2854146

I've worked in code bases like this, although not in Google. I think it's a good way to go but it does increase code size and sometimes you end up doing some convoluted dances with trying to change behavior based on a flag.

Also, good hygiene is important and implementing some kind of tracking ("no more than N flags older than X") is IMO a good practice. I wonder how Google does this?

I recall that folks did analyze this, every server running in production has its flags logged, and every command line tool run on user workstations is also logged. Then it's just a matter of having a registry of every flag (aka the source code) and diffing the set of flags used vs declared. As you would imagine most flags were never used.

Now removing them is another thing entirely -- but some teams do have code cleanup fixits.

Yes it does make source code smaller and simplier to read. But if you're referring to binary code size - well it pales in comparison to what protobuf contributes to generated code size. I'd say that proto code makes up >60% of Google binary size.

Yea, a lot of the core libraries at Google have flags in them, so when you link them into your cli, you get those flags as well.

They once submitted a patch to raise the Linux kernel’s limit on process command lines, because 128 KB was no longer enough for all their flags.

is there a source for this patch?

I am not a global variable sir, I am a command line flag.

"gflags:" https://gflags.github.io/gflags/

*Not to be confused with the windows sdk utility of the same name

Also, https://abseil.io/docs/cpp/guides/flags

Ha yes, yes it is. There are so many flags in a typical google3 program that there are a bunch of metaflags to change the way the usage message is printed. Because --helpfull is going to show you several megabytes of junk.

The Bazel documentation does tend to repeat them in multiple sections, though.

It also doesn't include many "undocumented"/experimental flags, which are hidden in release notes or only mentioned in the source code.

because there are no branches in google3 (the monorepo which stores virtually all internal code) flags are used to guard code paths rather than branches.

E.g I know in just one client-facing app there is well over a thousand flags, all individually owned and monitored by various individuals and teams wishing to either experiment or launch features.