Nothing particularly notable here. A lot of it seems to be 'We have something in-house designed for our use cases, use that instead of the standard lib equivalent'.<p>The rest looks very reasonable, like avoiding locale-hell.<p>Some of it is likely options that sand rough edges off of the standard lib, which is reasonable.
> We have something in-house designed for our use cases, use that instead of the standard lib equivalent<p>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.<p>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.
> 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.<p>The STL makes you pay for ABI stability no matter if you want it or not. For some use cases this doesn't matter, and there are some "proven" parts of the STL that need a lot of justification for substitution, yada yada std::vector and std::string.<p>But it's not uncommon to see unordered_map substituted with, say, sparsehash or robin_map, and in C++ libraries creating interfaces that allow for API-compatible alternatives to use of the STL is considered polite, if not necessarily ubiquitous.
... and for many of those blank .cpp file projects, the style guide should probably just read "start a blank .rs file instead."
Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:<p>> 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.<p>The problem is that too many people drank too much koolaid and trying to parrot everything to a letter without understanding the bigger picture.<p>The best example would be Kubernetes. Employed by many orgs that have 20 devs and 50 services.
Seeing the comments here talking about ancient codebases got me wistful for when Chromium was new and everything seemed possible.<p>That triggered a flash of feeling extremely old realizing we broke ground on this codebase 20 years ago this year!
There are yet more interesting docs in the parent directory :)<p><a href="https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++" rel="nofollow">https://chromium.googlesource.com/chromium/src/+/main/styleg...</a>
Exceptions are banned, but an exception is made for Windows.
You almost never see a list of banned Java features (or even banned C# features). On the other hand any serious C++ development team is going to have a list of banned features. Java eliminated the features that you would want to ban.
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.<p>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.<p>They're just languages, there's no reason to pretend they're perfect.
> 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.<p>Almost all of this is incorrect or comparing apples to oranges.<p>.net framework and .net core are runtime and standard library impl, not languages. C# is a language that can target either runtime or both. Framework is still supported today, and you can still use most modern C# language features in a project targeting it. WPF and Maui are both still supported and widely used. ASP predates .net - c# was never a supported language in it. ASP.net core has largely replaced ASP.net, but it's again a library and framework, not a language feature.<p>Dynamic in c# and the dlr are definitely not widely used because it's both difficult to use safely and doesn't fit well with the dominant paradigm of the language. If you're looking for STD lib warts binaryserializer would have been an excellent example.
Those are libraries not language features.
In C#, you would normally implement rules like this with a custom Roslyn Analyzer or with <a href="https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyzers/Microsoft.CodeAnalysis.BannedApiAnalyzers/BannedApiAnalyzers.Help.md" rel="nofollow">https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyze...</a>. 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.
> You almost never see a list of banned Java features ...<p>The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.<p>0 - <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2" rel="nofollow">https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...</a>
As a Java programmer I can only think of one thing:<p>Reflection - unless you really need to do something fancy almost certainly a very bad idea in normal application code.<p>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.<p>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.
Where does it list the preferred alternatives to banned features?<p>For example:<p>> The <filesystem> header, which does not have sufficient support for testing, and suffers from inherent security vulnerabilities.
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 <a href="https://www.chromium.org/developers" rel="nofollow">https://www.chromium.org/developers</a>, as that's where all the information for folks who actually need to know that kind of thing lives.
The banned list proves that context matters more than having the newest tools. These features work well for small apps but they cause problems in a project this size.
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.<p>They’d rather see it done the same way it would’ve been in any other similar language than with a language specific feature.<p>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).
Agreed. I also prefer conformity over sporadic use of new features going against an already set of standards in a codebase. it's overall less cognitive load on whoever is reading it imho.
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.
Is there a way to make this formal, like in the code, making the compiler complain when you try to use these features?
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
I'd curious about the banned Rust features. Surely, Rust has at lot fewer foot guns, but it isn't that there aren't <i>any</i>.
This list is longer than the features in all of C I feel like at first glance. Wow that is overwhelming.
Good call on those u8"..." literals.<p>Source code should all be UTF-8 natively, letting you directly write UTF-8 text between quotes.<p>Exactly their rationale.<p>These literals are a solution in search of a problem ... which is real but has a much better solution.
It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
> 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.<p>They are clearly not against them <i>per se</i>. It simply wasn't practical for them to include it into their codebase.<p>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).
My issue with exceptions is also practical. If they didn't introduce significant stability issues, I'd have no problem. As it stands, it's impossible to write robust software that makes use of C++ exceptions.<p>> the compiler will require you to deal with it somehow in g<p>I agree, this is the sensible solution.
In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability.<p>Exceptions in high-level languages avoid many of these issues by virtue of being much further away from the metal. It is a mis-feature for a systems language. C++ was originally used for a lot of high-level application code where exceptions might make sense that you would never use C++ for today.
> In low-level systems software, which is a primary use case for C++<p>I don't this this is true. There is A LOT of C++ for GUI applications, video games, all kind of utilities, scientific computing and others. In fact, I find that the transition to "modern" alternatives from native GUI toolkits in C/C++ has led to a regression in UI performance in general. Desktop programs performed better 20 years ago when everything was written in Win32, Qt, GTK and others and people did not rely on bloated Web toolkits for desktop development. Even today you can really feel how much more snappy and robust "old school" programs are relative to Electron and whatnot.
To clarify, you think that low-level systems software is only a secondary use case for C++? The part you quoted does not make claims about whether there are other primary use cases, just that low-level systems software is one of them, so it's not clear why it being useful elsewhere is a rebuttal of that.
> In low-level systems software, which is a primary use case for C++<p>I can assure you: Most C++ SW is not written for low-level.<p>> exceptions can introduce nasty edge cases that are difficult to detect and reason about.<p>That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception.<p>BTW, I'm not saying C++'s exceptions are in any way good. My point is that exceptions are bad <i>in C++</i>, and not necessarily bad in general.
The model of communicating errors with exceptions is really nice. The implementation in C++ ABI's is not done as well as it could be and that results in large sad path perf loss.
> That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception.<p>Sometimes it is not safe to unwind the stack. The language is not relevant. Not everything that touches your address space is your code or your process.<p>Exception handlers must have logic and infrastructure to detect these unsafe conditions and then rewrite the control flow to avoid the unsafety. This both adds overhead to the non-exceptional happy path and makes the code flow significantly uglier.<p>The underlying cause still exists when you don't use exceptions but the code for reasoning about it is highly localized and usually has no overhead because you already have the necessary context to deal with it cleanly.
If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit.<p>Exceptions are <i>more robust</i>, not less.
C++ exceptions are fast for happy path and ABI locked for sad path. They could be much faster than they are currently. Khalil Estell did a few talks/bunch of work on the topic and saw great improvements. <a href="https://youtu.be/LorcxyJ9zr4" rel="nofollow">https://youtu.be/LorcxyJ9zr4</a>
> "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability."<p>Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.
FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint.<p>There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely.<p>A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually.
Exceptions are actually a form of code compression. Past some break even point they are a net benefit, even in embedded codebases. They're "bad" because the C++ implementation is garbage but it turns out it's possible to hack it into a much better shape:<p><a href="https://youtu.be/LorcxyJ9zr4" rel="nofollow">https://youtu.be/LorcxyJ9zr4</a>
Is this correct? I don't know F# but I thought it had unchecked exceptions. How does it handle using C# libs that throw unchecked exceptions?
My memory of F# is very rusty, but IIRC, there are two types of error handling mechanisms. One of them is to be compatible with C#, and the other is fully checked.
The “pros” list is exceptionally weak. This was clearly written by someone who doesn’t like exceptions. Can’t blame them.
Most codebases that ban exceptions do it because they parrot Google.<p>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.<p>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.<p>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.<p>In such scenario there's no error recovery, software is expected to shutdown and raise loud error.
If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
Sometimes it’s useful to handle the exception somewhere near its origin so you can close related resources, lockfiles, etc. without needing a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred.
Your process can crash or be killed at any moment anyway. Depending on in-band cleanup is not reliable.
> a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred<p>... That seems like a pretty accurate description of how exception handling mechanisms are implemented under the hood. :)
The code that's throwing an exception typically does not know that the exception catcher will shut anything down.<p>And - very often, you would _not_ shut down. Examples:<p>* Failure/error in an individual operation or action does not invalidate all others in the set of stuff to be done.<p>* Failure/error regarding the interaction with one user does not mean the interaction with other users also has to fail.<p>* Some things can be retried after failing, and may succeed later: I/O; things involving resource use, etc.<p>* Some actions have more than one way to perform them, with the calling code not being able to know apriori whether all of them are appropriate. So, it tries one of them, if it fails tries another etc.
> They're good for exceptional situations where foundamental, core assumptions are broken for some reason.<p>No, that's what assertions or contracts are for.<p>Most exceptions are supposed to be <i>handled</i>. The alternative to exceptions in C++ are error codes and `std::expected::. They are used for errors that are <i>expected</i> to happen (even if they may be exceptional). You just shouldn't use exceptions for control flow. (I'm looking at you, Python :)
Yet, if you can only explain an exception using the word ‘exception’ you’re not making any head way.<p>I like the idea of an exception as a way to blow out of the current context in order for something else to catch it and handle in a generic manner. I don’t like the idea of an exception to hide errors or for conditional logic because you have to know what is handling it all. Much easier to handle it there and then, or use a type safe equivalent (like a maybe or either monad) or just blow that shit up as soon as you can’t recover from the unexpected.
I use asserts for this purpose.
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?!?<p>On banning exceptions:"Things would probably be different if we had to do it all over again from scratch."<p><a href="https://google.github.io/styleguide/cppguide.html#Exceptions" rel="nofollow">https://google.github.io/styleguide/cppguide.html#Exceptions</a>
Rust is too complicated!!11 Ooops wrong thread.
Since Chromium stopped allowing manifest-v2 extensions, i.e. significantly crippled what extensions can do and made it impossible to use some key extensions like uBlock Origin, I've decided to avoid it.<p>Anyway, about these C++ conventions - to each software house its own I guess. I don't think banning exceptions altogether is appropriate; and I don't see the great benefit of using abseil (but feel free to convince me it's really that good.)
Modules are banned - they should have just copied D modules.
C++ itself should be forever banned