the Chromium logo

The Chromium Projects

C++ intro

As with any large project, developing for Chromium will be much easier with a better understanding of the technology, languages, and most frequently used concepts and abstractions. This page is intended to provide links to resources, guides, and codelabs that will help kickstart your Chromium development career.

Style guides

Similar to internal Google development, Chromium development follows style guides whose goal is largely to document and manage the "dos and don'ts" of authoring code within Chromium. These are the Chromium C++ style guide and Google C++ style guide.


Chromium has a C++ 101 codelab that will help introduce developers to C++ development with Chromium, and includes coverage of threads, task runners, callbacks, Mojo, and more! This codelab can be found at codelabs/.

Tips of the week

While the C++ "Tips of the Week" occasionally reference concepts specific to internal Google C++ development, the vast majority of these articles are excellent resources on general C++ development best practices. Many of these are available publicly.

Chromium code directories

Note: If you run into a situation where the code you're writing in, say, //ash needs to depend on something in //chrome, delegates can be used to invert the dependency.

Chromium containers

Chromium provides a small library of containers (e.g. maps, queues, stacks) in //base/containers -- see the readme here.

Don't always assume that the std library containers are the best option; base containers can provide better memory or runtime performance than std library containers in many common use cases. For example, base::flat_map is a great memory-efficient alternative to std::map or std::unordered_map if the map only has a few elements or is rarely accessed.

Threading in Chromium


Callbacks in Chromium

Learn more about callbacks and how they are used within Chromium here. See also talk "Callbacks in Chromium" in CrOS 101.

Switch statements

Default cases

Google C++ Style Guide says if not conditional on an enum class, switch statements should always have a default case. If the default case should never execute, treat this as an error (see Defensive and Offensive Coding below).

Generally, you should always avoid using default on an enum class to ensure you're hitting every case and to ensure that any new case added to the enum is the future is handled. The compiler will emit a warning if you'are not covering every case.


The [[fallthrough]] attribute should be used in switch statements to indicate intentionally falling to the next case.

case 1:
case 2: