前情提要

看過了第一部分的概述和第二部分的 culture 我們來到了第三個部分：Process；這部分針對更加具體的軟體工程執行展開論述，這篇部落格從第 8 章 Style Guide 講起，談談書中的部分和我的學習心得。

Style Guides and rules

Rules are laws. They are not just suggestions or recommendations, but strict, mandatory laws.

這個部分中主要介紹了 Google 對於開發中的規則指導，特別是開發語言中的規範。這些規則在開源網站上可以查到 Google Style Guide

舉個例子：Google 的 C++ Style 裡面禁用了 exception 的概念。這裡我們貼出 Style Guide 的原文：

• When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f()
  calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.
• More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.
• Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.
• Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.
• The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

看到這些非常仔細的思考，可以讓人意識到謹慎使用 Exception 的重要性。

Principles of Rules

Pull their weight

無需因為大家都知道的事情而加重心智負擔，如 goto 的禁用是大家都知道的事情。

Optimize for the reader

這一點在整本書中都有明確的體現，特別是對於這本書中最多的 C++ 示例。這裡不加討論地貼出對於 unique_ptr 的說明：

在後面的說明中也提到，Google 對於 smart pointer 一開始沒有作為 style guide 而是在不斷髮展過程中認識到了 unique_ptr 的可讀性和 move semantic 的重要意義。

同時，對於 C++ 開發來說，const 的問題是逃不過去的，特別是對於 const return 和 const call 這種需要雙方實現的關鍵字約束。

Rules for style Guide

• Rules to avoid dangers
• Rules to enforce best practices
• Rules to ensure consistency

作為有效的 style guide 應當保證 consistency，同時帶有工具的支援，如進行自動化檢測等。同時，這一部分最有趣的是 Bikeshed 車棚討論。比如 Python 是幾個空格的縮排，關鍵的不是我們需要決定什麼，而是我們已經決定了這件事。