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
< BACK NEXT >
Tweet


   


   

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