Reformatting 100k Files at Google in 2011
Auto-formatting at scale, exemplified by Google’s 2011 effort to reformat nearly 200k BUILD files, is presented as a way to enable powerful tooling, reduce bikeshedding over style, and keep a massive monorepo maintainable. Commenters weigh the benefits of a single, non-configurable style (like Go’s gofmt) against the loss of personal formatting choices and the burden such rules can place on “code janitors” doing large-scale changes. The thread also touches on how infrastructure (formatters, refactoring tools, global approvers, VCS features) and even alternative representations of code (ASTs instead of text) might mitigate the pain of bulk rewrites and improve long‑term code health.
Autoformatters: perceived benefits
- Many commenters praise autoformatting for reducing cognitive load and bikeshedding, especially in large teams and corporate environments.
- Consistent formatting makes diffs and large codemods clearer, enabling tools that rewrite code (e.g., for migrations or dependency fixes) to operate without introducing spurious changes.
- Having a single, non-configurable formatter (as with Go) is viewed as an important “innovation” because it prevents endless debate about configuration knobs.
- Some describe autoformatters as bringing most code up to a “90th percentile” readability, which helps everyone who has to read others’ code.
Autoformatters: criticisms and limits
- Several participants dislike strict formatters that remove “maker’s marks” like deliberate blank lines, alignment, or grouping of functions, arguing that this harms readability and expressiveness.
- Concerns include autoformatters over-optimizing for uniformity, making hand-formatted tables or mapping literals harder to read, and being frustrating when the formatter authors ignored things some programmers care about.
- Some feel formatters are ideal for work code but not for solo or hobby projects where personal style and aesthetics matter.
Mandatory formatting and large-scale changes at Google
- The mass reformatting of ~200k BUILD files is defended as necessary to avoid future noisy diffs and to prevent an “unfunded mandate” where every future editor must deal with mixed styles.
- Google’s Perforce-based setup made “two-commit” patterns (semantic vs. formatting) harder than in Git/Mercurial; instead, a small team did large, carefully tested mechanical changes, sometimes with global approval.
- There is debate over incremental vs. whole-file formatting. Incremental formatters exist, but tools like buildozer often trigger full rewrites, causing review friction when only small semantic changes were intended.
- One participant argues that evolving formatting rules without strict enforcement or dedicated staffing imposes a disproportionate cost on “janitors” doing large-scale cleanups.
Alternative representations (AST/binary source)
- A recurring idea is storing programs as ASTs or other structured/binary formats, then rendering to each developer’s preferred formatting.
- Others push back: ASTs miss many stylistic choices (blank lines, line breaking), complicate invalid/partial code handling, and lose the advantages of simple text and existing tooling.
Tooling and ecosystem
- Multiple Bazel/BUILD tools are mentioned (buildifier, buildozer, internal dependency updaters, gazelle), with the point that uniform formatting is what makes such tooling practical and reliable.
Culture, bikeshedding, and style
- Debate touches on whether time spent arguing about formatting reflects true preference or just human irrationality.
- Some insist that at work, personal style should yield to team consistency; others emphasize that code is a creative artifact and that pride in one’s stylistic choices is legitimate.