bi-06 — Analysis

The two bars, kept separate

BarRequires
Reading Chromium C++ownership idioms, callbacks, threading annotations, Oilpan handles, the ability to skip
Writing a landable CLthe above, plus local style, correct handle types, no lifetime bugs

Conflating them is why people over-prepare. You do not need template metaprogramming, the algorithm catalogue, or exception handling — Chromium builds without exceptions, which removes a large region of normal C++ from consideration.

Required invariants when you write

  1. Every pointer answers "who owns this." unique_ptr sole, scoped_refptr shared, raw_ptr non-owning member, Member<T> graph edge inside the GC heap.
  2. Every callback answers "what keeps the receiver alive." Ownership, scoped_refptr, WeakPtr (may not run), or Unretained (a promise you must verify).
  3. Every object with a SEQUENCE_CHECKER belongs to one sequence. Touching it elsewhere is a bug the checker will catch in a dcheck_always_on build.
  4. CHECK vs DCHECK classifies the failure. Security or memory-safety ⇒ CHECK; a wrong pixel ⇒ DCHECK.

How the codebase enforces its rules

Blink's type conventions are enforced three ways at once: DEPS, audit_non_blink_usage.py, and a clang plugin. Three-mechanism enforcement is a signal about how often people got it wrong, and about how seriously reviewers will treat it.

That is worth generalising: when you find yourself writing a convention document, ask what would make it mechanically checkable. A rule nobody can violate accidentally is worth ten rules everyone agrees with.

The reading skill that matters most

Distinguishing house style from migration in progress. raw_ptr and base::span are partially rolled out; copying the pattern next to your change may copy the old one, and a reviewer will ask you to change it. Look for the newest code in the file, not the nearest.