这是现代C ++，C ++ 17，C ++ 14和C ++ 11的一套核心指南，考虑了未来的增强功能和ISO技术规范（TS）。 目的是帮助C ++程序员编写更简单，更高效，更易维护的代码。

简介摘要：

• 适用读者群
• 宗旨
• 非主要目标
• 规范
• 文档结构
• 主要内容

使用读者群

适用于所有C++编程者以及C语言编程

宗旨

本文档的目的是帮助开发人员采用现代C ++（C ++ 17，C ++ 14和C ++ 11），并在代码库中实现更统一的风格。
我们不会妄图这些规则中的每一个都可以有效地应用于每个代码库。 升级旧系统很难。 但是，我们确实认为使用规则的程序比不使用规则的程序更不容易出错且更易于维护。 通常，规则也会导致更快/更容易的初始开发。 据我们所知，这些规则导致代码的表现与旧的，更传统的技术一样好或更好; 它们意味着遵循零开销原则（“你不使用什么，你不付钱”或“当你适当地使用抽象机制时，你至少获得了良好的性能，就像你用较低的手写代码一样 级别语言构造“）。 考虑这些规则对新代码的理想，在处理旧代码时利用的机会，并尝试尽可能接近这些理想。 记得：

Note

花点时间了解指南规则对你的程序将会产生深远影响

这些指南是根据“超集子集”原则(Stroustrup05)设计的。 它们不是简单地定义要使用的C ++子集（用于可靠性，安全性，性能等）。 相反，他们强烈建议使用一些简单的"extensions"(library components，这些扩展使得C ++中容易出错的最容易出现的特性变得冗余，从而可以禁止它们（在我们的规则集中）。

规则强调静态类型安全和资源安全。 出于这个原因，他们强调范围检查的可能性，避免解除引用nullptr，避免悬空指针，以及系统使用异常（通过RAII）。 部分是为了实现这一目标，部分是为了最大限度地减少模糊代码作为错误的来源，规则还强调简单性和隐藏在指定良好的接口背后的必要复杂性。

许多规则都是规定性的。 我们对简单地说 "don't do that!"的规则感到不安！ 没有提供替代方案。 其中一个结果是，某些规则只能通过启发式方法来支持，而不是通过精确和机械可验证的检查。 其他规则阐明了一般原则。 对于这些更一般的规则，更详细和具体的规则提供部分检查。

这些指南解决了C ++的核心及其用途。 我们希望大多数大型组织，特定应用领域甚至大型项目都需要进一步的规则，可能还需要进一步的限制，以及进一步的图书馆支持。 例如， hard-real-time程序员通常不能自由使用免费存储（动态内存），并且会限制他们选择的库。 我们鼓励制定更具体的规则作为这些核心准则的附录。 构建理想的小型基础库并使用它，而不是降低编程水平以获得美化的汇编代码。

这些规则旨在逐步采用.
一些规则旨在增加各种形式的安全性，而其他规则旨在减少事故发生的可能性，许多规则都是这样做的。 旨在预防事故的指导方针通常禁止完全合法的C ++。 然而，当有两种表达想法的方式，一种表现出共同的错误来源而另一种却没有，我们试图引导程序员走向后者。

非主要目标

一般规则不是最小的或者其交集， 特别是，一般规则可以很简单，但不可执行； 此外，通常很难理解一般规则的含义。 更专业的规则通常更容易理解和执行，但如果没有一般规则，它们只是一长串的特殊情况。 我们提供旨在帮助新手的规则以及支持专家使用的规则。 一些规则可以完全实施，但其他规则基于启发式。
这些规则并不意味着像书本一样连续阅读。 您可以使用链接浏览它们。 但是，它们的主要用途是成为工具的目标。 也就是说，工具会查找违规行为，并且该工具会返回违反规则的链接。 然后，规则提供了理由，违规的潜在后果的示例以及建议的补救措施。

这些指南并非旨在替代C ++的教程处理。 如果您需要针对某些特定经验水平的教程，请参阅参考资料.

这不是如何将旧的C ++代码转换为更现代的代码的指南。 它旨在以具体的方式阐明新代码的想法。 但是，请参阅the modernization section,一些可能的现代化/恢复/升级方法。 重要的是，规则支持逐步采用：一次完全转换大型代码库通常是不可行的。

这些指南并不意味着在每种语言技术细节上都是完整或准确的。 有关语言定义问题的最终结论，包括一般规则和每个功能的每个例外，请参阅ISO C ++标准。

这些规则并不是为了强迫您在C ++的贫困子集中编写。 它们 着重并不意味着定义一个类似Java的C ++子集。 它们并不意味着定义单一的 one true C++语言。 我们重视表现力和不妥协的表现。

规则不是价值中立的。 它们旨在使代码比大多数现有C ++代码更简单，更正确/更安全，而不会降低性能。 它们旨在抑制与错误，虚假复杂性和糟糕性能相关的完全有效的C ++代码。

规则并不完美。 通过禁止在特定情况下有用的东西，规则可能会造成伤害。 规则可能会因为未能禁止在特定情况下出现严重错误的内容而造成伤害。 规则可以通过有歧义，模糊，不可执行或通过启用问题的每个解决方案来做很多伤害。 完全不符合 "do no harm" 标准是不可能的。 相反，我们的目标是不那么雄心勃勃："Do the most good for most programmers"；如果你不能遵守规则，反对它，忽略它，但不要把它淡化到毫无意义。 否则，建议改进。

规范

对于大型代码库，没有强制执行的规则是不可管理的。所有规则的强制执行只能针对一小部分弱规则或特定的用户社区。

• 但是我们需要很多规则，而且我们需要每个人都可以使用的规则。

• 但是不同的人有不同的需求。

• 但是人们不喜欢阅读很多规则。

• 但人们不记得很多规则。
  因此，我们需要特例来满足各种需求。

• 但任意子集导致混乱。
  我们需要能够帮助很多人的指南，使代码更加统一，并强烈鼓励人们对代码进行现代化。 我们希望鼓励最佳实践，而不是将所有实践留给个人选择和管理压力。 理想的是使用所有规则; 这给了我们最大的好处。
  这加起来有很多困境。 我们尝试使用工具解决这些问题。 每个规则都有一个执行部分，列出了强制执行的想法。 可以通过代码审查，静态分析，编译器或运行时检查来执行强制执行。 在可能的情况下，我们更喜欢“机械”检查（humans are slow, inaccurate, and bore easily）和静态检查。 在没有替代方案的情况下，很少建议运行时检查; 我们不想介绍"distributed fat"。 在适当的情况下，我们使用相关规则组(called "profiles").的名称标记规则(in the Enforcement sections）。 规则可以是多个配置文件的一部分，也可以不是。 首先，我们有一些与常见需求（desires, ideals)相对应的配置文件：

• type: 没有类型违规(reinterpreting a T as a U through casts, + + unions, or varargs)

• bounds: 没有边界违规 (accessing beyond the range of an array)

• lifetime: 没有内存泄露 (failing to delete or multiple delete) and no access to invalid objects (dereferencing nullptr, using a dangling reference).
  这些配置文件旨在供工具使用，但也可以作为人类读者的帮助。 我们不会将执行部分中的评论限制在我们知道如何执行的内容中; 一些评论只是希望可能激发一些工具制造者。
  实现这些规则的工具应遵循以下语法来明确禁止规则：

  [[gsl::suppress(tag)]]
  

其中“tag”是执行规则出现的项目的锚名称(e.g., for C.134 it is "Rh-public"),是规则组规则的名称("type", "bounds", or "lifetime"),或配置文件中的特定规则(type.4, or bounds.2)。

文档结构

每条规则（指南，建议）可以有几个部分：

• The rule itself -- e.g., no naked new
• A rule reference number -- e.g., C.7 (the 7th rule related to classes). Since the major sections are not inherently ordered, we use letters as the first part of a rule reference "number". We leave gaps in the numbering to minimize "disruption" when we add or remove rules.
• Reasons(rationales) -- because programmers find it hard to follow rules they don't understand
• Examples -- because rules are hard to understand in the abstract; can be positive or negative
• Alternatives -- for "don't do this" rules
• Exceptions -- we prefer simple general rules. However, many rules apply widely, but not universally, so exceptions must be listed
• Enforcement -- ideas about how the rule might be checked "mechanically"
• See alsos -- references to related rules and/or further discussion (in this document or elsewhere)
• Notes (comments) -- something that needs saying that doesn't fit the other classifications
• Discussion -- references to more extensive rationale and/or examples placed outside the main lists of rules
  有些规则难以机械检查，但它们都符合专家程序员可以毫不费力地发现许多违规行为的最低标准。 我们希望“机械”工具能够随着时间的推移而改进，以接近这样的专家程序员注意到的内容。 此外，我们假设规则将随着时间的推移而得到改进，以使其更加精确和可检查。
  规则旨在简单，而不是仔细地措辞，以提及每个替代和特殊情况。 此类信息可在备选段落和讨论部分中找到。 如果您不理解规则或不同意规则，请访问其讨论。 如果您认为讨论缺失或不完整，请输入一个问题，解释您的疑虑以及可能的相应PR。
  这不是语言手册。 它旨在对技术细节或现有代码指南提供有用而非完整的准确性。 推荐信息来源可在参考文献中找到。