In.struct: The structure of this document（本文档的结构）
Each rule (guideline, suggestion) can have several parts:
每条规则（指南，建议）都会包含几个部分：
。The rule itself -- e.g., no naked new
规则本身--例如：避免直接使用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.
规则的参照编号--例如，C.7(于类相关的第七条规则）。由于主要分区没有自然排序，我们使用字母作为规则参照编号的第一部分。我们在编号之间留出空隙是希望将增加或者删除规则时的影响降到最低。
。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
讨论 -- 置于主规则清单之外的进一步展开的根据和/或例子。
Some rules are hard to check mechanically, but they all meet the minimal criteria that an expert programmer can spot many violations without too much trouble. We hope that "mechanical" tools will improve with time to approximate what such an expert programmer notices. Also, we assume that the rules will be refined over time to make them more precise and checkable.
某些规则很难被机械化检查，但是它们都符合一个标准：专家程序员可以很容易识别出违反它们的情况。我们希望“机械化”工具随着时间的推移可以尽量接近专家程序员的水平。同时我们也认为：随着时间的推移，规则会不断被完善而变得更加精确和可检查。
A rule is aimed at being simple, rather than carefully phrased to mention every alternative and special case. Such information is found in the Alternative paragraphs and the Discussion sections. If you don't understand a rule or disagree with it, please visit its Discussion. If you feel that a discussion is missing or incomplete, enter an Issueexplaining your concerns and possibly a corresponding PR.
规则会尽量简单，而不是小心的推敲以照顾到所有的可能和特殊的情况。这类信息会在可选项段落和讨论区记述。如果你没有理解某条规则或者反对它，请参考讨论部分。
This is not a language manual. It is meant to be helpful, rather than complete, fully accurate on technical details, or a guide to existing code. Recommended information sources can be found in the references.
这不是一部语言手册。它当然是有用，但不是包罗万象的，也不保证所有技术细节都正确，也不是现存代码的指南。推荐的信息源可以查阅参考资料部分。
In.sec: Major sections（主要分区）
。In: Introduction（介绍）
。P: Philosophy（基本原则）
。I: Interfaces（接口）
。F: Functions（函数）
。C: Classes and class hierarchies（类和继承）
。Enum: Enumerations（枚举）
。R: Resource management（资源管理）
。ES: Expressions and statements（表达式和陈述）
。Per: Performance（性能）
。CP: Concurrency and parallelism（并发和相似性）
。E: Error handling（错误处理）
。Con: Constants and immutability（常量和不变性）
。T: Templates and generic programming（模板和泛型编程）
。CPL: C-style programming（C风格编程）
。SF: Source files（源代码）
。SL: The Standard Library（标准库）
Supporting sections:
。A: Architectural ideas（结构方面的想法）
。NR: Non-Rules and myths（伪规则和传言）
。RF: References（参考资料）
。Pro: Profiles（规则侧面）
。GSL: Guidelines support library（指南支持库）
。NL: Naming and layout rules（命名和布局规则）
。FAQ: Answers to frequently asked questions（常见问题回答）
。Appendix A: Libraries（库）
。Appendix B: Modernizing code（现代化代码）
。Appendix C: Discussion（讨论）
。Appendix D: Supporting tools（支持工具）
。Glossary（术语表）
。To-do: Unclassified proto-rules（未完事项：未分类规则原型）
These sections are not orthogonal.
各个分区之间并非正交关系。
译者注：有可能存在重复
Each section (e.g., "P" for "Philosophy") and each subsection (e.g., "C.hier" for "Class Hierarchies (OOP)") have an abbreviation for ease of searching and reference. The main section abbreviations are also used in rule numbers (e.g., "C.11" for "Make concrete types regular").
每个分区（例如：P代表基本原则）和每个子分区（例如，C.hier代表面向对象编程（OOP）中的类层次关系）都有一个缩略语以便检索和参照。主分区的缩略语也用于规则编码（例如，“C11”代表“让具象类型有规律”）
觉得本文有帮助，欢迎点赞并分享给更多的朋友。
阅读更多更新文章，请关注微信公众号【面向对象思考】
