Software Engineering at Google Chapter #8 - Style Guides and Rules (3 of 3)

  • Things that don’t really matter but need to be decided and consistent (naming conventions, import ordering, etc)
  • Fundamental engineering advice:
    • Don’t reinvent the wheel
    • Don’t fork the codebase
    • Don’t be clever
  • If a rule is causing engineers to spend time circumventing it, then the rule is probably not necessary or needs to be changed
  • Decisions behind rule choices should be backed by evidence and documented (the rule and its reason + evidence)
  • Changing rules should be “solution based” meaning - call out the problem, provide a solution. Use patterns in code to identify “problems”
  • Anyone in the organization can propose a style guide change
  • Rule changes can be a well polished proposal or a small discussion that starts a larger discussion
  • Consider a style guide group or committee instead of an individual owner. Also consider this group have an even number of members
  • Exemptions to the style guide are possible, but should be very rare
  • Rules are “musts”, guidance is “should” - a guideline
  • Consider a “How Programming Language X at MyCorP Works” course in order to teach new employees the nuances of how the organization code in a particular language
  • Create code-base references and cheat sheets for new engineers
  • Automate rule enforcement via tooling to make it consistent and scalable
  • Some rules are social rather than technical (what is a “small” PR?)
  • Error checkers and validation systems override the need for the author to remember all rules
  • Use code formatters and style checkers
< BACK NEXT >
Tweet


   


   

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