> We have something in-house designed for our use cases, use that instead of the standard lib equivalent

Yea, you encounter this a lot at companies with very old codebases. Don't use "chrono" because we have our own date/time types that were made before chrono even existed. Don't use standard library containers because we have our own containers that date back to before the STL was even stable.

I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.

Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:

> Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.

Not an Googler, but my, probably way too much romanticized, understanding of Google was that they never ask you about specific tech because for everything there's an in-house version.

The problem is that too many people drank too much koolaid and trying to parrot everything to a letter without understanding the bigger picture.

The best example would be Kubernetes. Employed by many orgs that have 20 devs and 50 services.

In C#, you would normally implement rules like this with a custom Roslyn Analyzer or with https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyze.... It’s fair to say C# projects tend to have smaller denylists than mature C++ projects, but banned APIs definitely exist in mature C# projects.

This seems factually incorrect and ignorant of history. Java has tons of things which shouldn't be used. Serialization (use Jackson now, not the built-in stuff), date/time (there's an entirely different namespace so you don't accidentally use garbage classes), etc.

C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.

They're just languages, there's no reason to pretend they're perfect.

> You almost never see a list of banned Java features ...

The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.

0 - https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...

As a Java programmer I can only think of one thing:

Reflection - unless you really need to do something fancy almost certainly a very bad idea in normal application code.

Other than that it’s either just limiting yourself to a specific JVM version or telling people not to use old syntax/patterns that were replaced with better options long ago.

I think Java has plenty of features that end up implicitly banned at least. e.g. you will really never see a `java.util.Vector` in any modern code base. No one `implements Serializable` anymore in practice. `Objects.equals()` and `Objects.hashCode()` get you through 99% of equals/hash code implementations. The list goes on.

I guess the difference is it's rarely "dangerous" or "hard to reason about" using the old features unlike what I see in the C++ list. Java replaces things with better things and momentum shifts behind them kind of naturally because the better things are objectively better.

I would imagine most codebases, even in modern languages, tend to have a list of banned features. Typically you use a linter to catch these.

grep'd "exception" and "Windows", tl;dr only Windows reference is for `[[no_unique_address]]`. Therefore I am probably missing a joke :)

For most of the banned library features, the preferred alternative is listed right there in the notes. <filesystem> is one of the exceptions.

base/files

Gonna venture a guess and say probably https://www.chromium.org/developers, as that's where all the information for folks who actually need to know that kind of thing lives.

I'm not a c++ user but i'm pretty sure you should be able to pull-off a macro to do that ; in c you could alias the lib for something that breaks + alert ; I don't know how I would integrate such additional compiler checks in rust for other kinds of rules however - it's interesting to think about

It is relatively easy to check these things with static analyzers, if nothing else.

It’s a bit different, but WebKit uses Clangs static analysis.

Kythe can be used for that

IIRC a big part of Google’s coding guidelines is also about making it easy for people not heavily invested in a specific language to contribute safely. So not necessarily a project size but rather an organizational concern.

They’d rather see it done the same way it would’ve been in any other similar language than with a language specific feature.

There are also portability concerns in mind given that projects like Chromium have to be easily portable across a vast amount of platforms (this shows with things like long long which is also on the list).

Some of it is historical reasons or portability more than anything else. Chrome is an old C++ project and evolved many of its own versions of functionality before standardization; and there's benefit to staying on its own implementations rather than switching.

Heard of `#![forbid(unsafe_code)]` ?

> Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch.

They are clearly not against them per se. It simply wasn't practical for them to include it into their codebase.

And I think a lot of the cons of exceptions are handled in languages like F#, etc. If f calls g which calls h, and h throws an exception, the compiler will require you to deal with it somehow in g (either handle or explicitly propagate).

Most codebases that ban exceptions do it because they parrot Google.

Google’s reasons for banning exceptions are historical, not technical. Sadly, this decision got enshrined in Google C++ Style Guide. The guide is otherwise pretty decent and is used by a lot of projects, but this particular part is IMO a disservice to the larger C++ ecosystem.

I think reasonable people can disagree about whether C++ exceptions are "good" or not.

There are things you can't do easily in C++ without using exceptions, like handling errors that happen in a constructor and handling when `new` cannot alloc memory. Plus, a lot of the standard library relies on exceptions. And of course there's the stylistic argument of clearly separating error-handling from the happy-path logic.

I won't argue that it's popular to ban them, though. And often for good reasons.

They're good for exceptional situations where foundamental, core assumptions are broken for some reason.

In such scenario there's no error recovery, software is expected to shutdown and raise loud error.

Looking at this ban list, they've removed everything from C++ that makes it fun. Come on people, who doesn't love a little std::function?!?

On banning exceptions:"Things would probably be different if we had to do it all over again from scratch."

https://google.github.io/styleguide/cppguide.html#Exceptions

If nothing else Abseil gives you state-of-the-art hashmaps that run circles around the STL ones, which are slow pretty much by definition. The spec precludes the modern ways of implementing them.