标签：Chapter Style Google Rules exception style exceptions Guide

前情提要

看过了第一部分的概述和第二部分的 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，可以看到有特别多针对语言实现详尽的细节。而且最有意义的是，每一条 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 是几个空格的缩进，关键的不是我们需要决定什么，而是我们已经决定了这件事。

标签：Chapter,Style,Google,Rules,exception,style,exceptions,Guide
来源： https://www.cnblogs.com/Sanhao99/p/16248894.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。