Software Engineering at Google Chapter #8 - Style Guides and Rules (1 of 3)
Style guides maintain the rules for governing codebases (much more than just “code style”)
Note that these are rules, not suggestions or recommendations - there is a difference
At Google there is a style guide for each programming language and each guide differs in length, scope,
Good and bad are subjective so what is good for one organization may not be good for another
By having rules in a style guide it points the engineer to what the organization values as “good”
Instead of asking which rules to create instead ask what your end goal is and create rules to get you
Your codebase should aspire to be resilient to both time and scale
Rules should do 3 things:
Pull their own weight
Each rule has a cost to be considered.
More rules make it challenging and expensive to both maintain and abide by the rule set
Optimize for the reader, not the writer.
The code will be read many more times than it will be written to.
Leave direct evidence of the code’s intended behavior.
Create clear evidence of object ownership (example being C++ pointers)
Documentation comments describe intent or design while implementation comments are used to highlight or
justify non-obvious choices that were made, point out important parts of the code, or explain tricky
Style guides allow engineers to jump into new code quickly
Consistency allows your engineering organization to scale - both technical and human
Consisten code allows for expert “chunking” (viewing things as meaningful “chunks” vs individual pieces)
for faster reading an analysis