Rules are laws - they're not just suggestions or recommendations, but rather mandatory laws that have to be followed. This point is emphasized as often, programmers usually look at style guidelines as "nice-to-haves" rather than strict rules - which might cause problems especially at scale. They can be enforced as rules by protecting the master branch with lint/formatting checks via CI (which we do in RepoSense), and automated with the usage of git hooks.
The main purpose of style rules is to promote good coding practices - they help form a common coding vocabulary regardless of developer background. These rules are often developed with important principles in mind, such as "each rule must justify its existence".
Of course, what can be considered "good" coding practices is not often 100% universal/objective. As the book was written from Google's perspective, it mentions that the people who are responsible for developing the style guides (in the book's context - engineering leadership at tech companies) have to first recognize what their organization values, before being able to develop rules/guidelines that align with those values. For instance, an organization in the trading sphere might view "good" practices as practices that support a small memory footprint or prioritize potential runtime optimizations.
By enforcing these rules, engineers can focus more on the business logic of their code rather than wasting time on syntax/style, which enhances productivity.
Here are some key points that Google used to develop their style guides:
Rules must pull their weight. Since there's a non-zero cost for each rule (adaptation/learning time), they have to bring about enough positive impact to justify this extra cost.
Optimize for the reader. Google prioritizes rules that optimizes the ease of reading code, rather than writing. The rationale is that code is read far more frequently than it is written, and so a rule that might require slightly more development time but results in better readability would be considered. The example provided is forcing the use of verbose if statements in Python, rather than one-liners (e.g. return 5 if <condition> else 6)
Be consistent. This principle applies much more to bigger organizations with hundreds or thousands of different codebases/projects, but the general idea is that style guides should be consistent across teams and codebases.
The last section of the chapter focuses on automation, and how automating the enforcement of style guides and rules whenever possible is beneficial. Many such tools exist, such as auto formatters in IDEs, linters, and even git hooks. Importantly, these should be introduced during the onboarding process for new developers, to ease the learning curve of the style guides and rules being enforced.
Book: SE@Google Chapter: Style Guides and Rules
Summary:
Here are some key points that Google used to develop their style guides:
return 5 if <condition> else 6)The last section of the chapter focuses on automation, and how automating the enforcement of style guides and rules whenever possible is beneficial. Many such tools exist, such as auto formatters in IDEs, linters, and even git hooks. Importantly, these should be introduced during the onboarding process for new developers, to ease the learning curve of the style guides and rules being enforced.