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, and content
  • 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 there
  • 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 sections.
  • Be consistent
  • 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



Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.