Reformatting 100k Files at Google in 2011

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.