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

  • Consistent code has less duplication
  • Better modularized code
  • Styles guides and consistent are resilient to time as people come and go from the project and for long term maintenance
  • Consider that perfect consistency may be too costly for the value
  • Global consistency is the goal, but if that’s not possible at least go for local consistency (within a software program, within an organization, etc)
  • Also consider your consistency (your company's style guide) vs external consistency (the official style guide for the language)
  • If possible, choose external standards (eg: use Python language standards instead of re-inventing your own)
  • Concede to practical concerns when necessary
  • Permit optimizations and practicalities even if they are not in the style guide - be a bit flexible
  • Google is forced to break some of their own C++ style guide rules due to the way software works on Microsoft Windows
  • Avoid error-prone and surprising constructs
  • Consider outlawing certain “power features”, patterns, or constructs that are dangerous or cause obfuscation
  • Style guide rules fall into three categories:
    • Rules to avoid danger
    • Things such as security, exception handling, multi-threading, and language features to avoid (essentially to avoid “subtle bugs”)
    • Rules to enforce best practices
  • Sytle guides and consistency keeps the codebase “healthy and maintainable”
  • Create documented structure around file structure, package structure, etc
  • Create limitations around new and not-yet-well-understood language features to get ahead of the curve to keep everyone consistent. After they are created, gather feedback to iterate on them
  • Rules to enforce consistency



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