C++核心准则边译边学-实施建议

In.force: Enforcement（实施建议）

Rules with no enforcement are unmanageable for large code bases. Enforcement of all rules is possible only for a small weak set of rules or for a specific user community.

对于大规模代码来说，不包含实施建议的规则是无法管理的。针对所有规则的实施建议只有在规则数量甚少，针对特定的用户群体时才可能存在。

• But we want lots of rules, and we want rules that everybody can use.但是我们想要很多规则，并且我们希望每个人都能用的规则。

• But different people have different needs.但是不同的人需求也不同。

• But people don't like to read lots of rules.但是人们不喜欢理解大量规则。

• But people can't remember many rules.但是人们不能记住大量的规则。

So, we need subsetting to meet a variety of needs.因此我们需要构造规则的子集以满足不同的需求。

• But arbitrary subsetting leads to chaos.但是随心所欲的构造子集会导致混乱。

We want guidelines that help a lot of people, make code more uniform, and strongly encourage people to modernize their code. We want to encourage best practices, rather than leave all to individual choices and management pressures. The ideal is to use all rules; that gives the greatest benefits.

我们帮助很多人的指南可以使代码更加统一，并且强烈推荐人们现代化他们的代码。我们希望鼓励最佳实践，而不是把一切留给个人选择和管理压力。这个想法适用于所有规则；这会带来巨大的利益。

This adds up to quite a few dilemmas. We try to resolve those using tools. Each rule has an Enforcement section listing ideas for enforcement. Enforcement might be done by code review, by static analysis, by compiler, or by run-time checks. Wherever possible, we prefer "mechanical" checking (humans are slow, inaccurate, and bore easily) and static checking. Run-time checks are suggested only rarely where no alternative exists; we do not want to introduce "distributed fat". Where appropriate, we label a rule (in the Enforcement sections) with the name of groups of related rules (called "profiles"). A rule can be part of several profiles, or none. For a start, we have a few profiles corresponding to common needs (desires, ideals):

这些想法加起来造成非常多的困扰。我们努力使用工具解决这些问题。每条规则都有一个实施建议用来列举实施相关的想法。实施的方式可以是通过代码评审，静态分析，编译器，或者执行时检查。只要可能，我们更加推荐机械检查（人的速度很慢，不准确并且容易厌烦）和静态检查。动态检查只有在没有其他备选出口时才会被推荐，这种情况很少；我们（在实施建议中）以一组相关规则的统称（称为“概述”）为规则打标签。规则可以是多个从属于多个不同的概述，或者不属于任何概述。作为开始，我们已经有几个概述用于对应常见的需求（愿望，理想）

译者注：再次强调静态检查。

觉得本文有帮助，欢迎点赞并分享给更多的朋友。

阅读更多更新文章，请关注微信公众号【面向对象思考】

• type: No type violations (reinterpreting a T as a U through casts, unions, or varargs)类型：没有类型违反（通过类型转换，联合或者可变参数将T重新解释为U）

• bounds: No bounds violations (accessing beyond the range of an array)范围：没有范围违反（超出数组范围访问）

• lifetime: No leaks (failing to delete or multiple delete) and no access to invalid objects (dereferencing nullptr, using a dangling reference).声明周期：没有泄漏（没有delete或多重delete）和访问无效对象（对空指针取值，使用野指针）

The profiles are intended to be used by tools, but also serve as an aid to the human reader. We do not limit our comment in the Enforcement sections to things we know how to enforce; some comments are mere wishes that might inspire some tool builder.

概述的目的是被工具使用，但也可以帮助人类读者。对用户那些我们知道如何实施的规则，我们不会在实施建议中吝惜我们的描述。有些解释仅仅是希望启发某些工具构建者的思考。

Tools that implement these rules shall respect the following syntax to explicitly suppress a rule:

实现这些规则的工具应该遵守下面的语法以便明确地抑制某条规则。

[[gsl::suppress(tag)]]

where "tag" is the anchor name of the item where the Enforcement rule appears (e.g., for C.134 it is "Rh-public"), the name of a profile group-of-rules ("type", "bounds", or "lifetime"), or a specific rule in a profile (type.4, or bounds.2).

这里“tag”是一个项目的锚名称，这里应该出现实施建议（例如对于C.134来说是“Rh-publicc”），规则组名称（“type”，“bounds”，或者“lefttime”），或者概述中的特定规则。

译者注：抑制的含义是忽略某条规则。