规则本身——例如，没有赤裸裸的新规则
引用号——例如，C.7(与类相关的第7条规则)。由于主要部分本身没有排序，所以我们使用字母作为规则引用“number”的第一部分。当我们添加或删除规则时，我们在编号中留下空隙以最小化“干扰”。
理由——因为发现程序员很难遵循他们不理解的规则。
例如——因为抽象的规则很难理解;不管是积极的还是消极的
替代——“不要这样做”规则的替代方法。
例外——我们更喜欢简单的一般规则。然而，许多规则应用广泛，但不是普遍的，因此必须列出例外情况．
执行——关于如何“机械地”检查规则的想法参见——相关规则和/或进一步讨论的参考(在本文件或其他地方)注释(注释)——需要说明但不适合其他分类的内容讨论——引用更广泛的基本原理和/或置于主要规则列表之外的例子。
有些规则很难机械地检查，但它们都满足了专家程序员可以毫不费力地发现许多违规的最低标准。我们希望“机械”工具将随着时间的推移而改进，以接近这样的专家程序员所注意到的。此外，我们假设规则将随着时间的推移而改进，使它们更精确和可检查。规则的目的是简单，而不是小心措辞，提到每一个替代和特殊情况。这些信息可以在备选段落和讨论部分找到。如果你不理解一个规则或不同意它，请访问它的讨论。如果你觉得一个讨论缺失或不完整，输入一个问题，解释你的关注，可能还有一个相应的公关。编写了示例来说明规则。示例不打算达到产品质量，也不打算涵盖教程的所有维度。例如，许多示例是与语言有关的，并使用诸如f、base和x之类的名称。
我们努力确保“好的”例子遵循核心准则。注释通常是用来说明规则的，在“真正的代码”中它们是不必要的或分散注意力的。我们假设了解标准库。例如，我们使用普通vector而不是std:: vector这不是语言手册。它旨在提供帮助，而不是在技术细节上完整、完全准确，或对现有代码的指导。推荐的信息来源可以在参考资料中找到。
