NL: Naming and layout rules
NL：命名和布局规则
Consistent naming and layout are helpful. If for no other reason because it minimizes "my style is better than your style" arguments. However, there are many, many, different styles around and people are passionate about them (pro and con). Also, most real-world projects includes code from many sources, so standardizing on a single style for all code is often impossible. After many requests for guidance from users, we present a set of rules that you might use if you have no better ideas, but the real aim is consistency, rather than any particular rule set. IDEs and tools can help (as well as hinder).
如果没有其他原因，一致的命名和布局是就有益的，因为它最小化了“我的风格比您的风格更好”的说法。但是，周围有很多很多不同的风格，人们对此充满热情（赞成和反对）。此外，大多数现实世界项目都包含来自许多来源的代码，因此，通常不可能对所有代码进行单一样式的标准化。在用户提出许多要求后，我们提出了一套规则，如果您没有更好的主意，则可以使用，但真正的目的是一致性，而不是任何特定的规则集。IDE和工具可以为某些规则提供帮助（也可以阻止某些规则）。
Naming and layout rules:
命名和布局规则：
NL.1: Don't say in comments what can be clearly stated in code
NL.1：请不要在注释中说代码中可以清楚说明的内容
NL.2: State intent in comments
NL.2：在注释中表达意图
NL.3: Keep comments crisp
NL.3：保持注释清晰
NL.4: Maintain a consistent indentation style
NL.4：保持一致的缩进样式
NL.5: Avoid encoding type information in names
NL.5：避免在名称中包含类型信息
NL.7: Make the length of a name roughly proportional to the length of its scope
NL.7：使名称的长度与范围的长度大致成比例
NL.8: Use a consistent naming style
NL.8：使用一致的命名方式
NL.9: Use ALL_CAPS for macro names only
NL.9：ALL_CAPS仅用于宏名称
NL.10: Prefer underscore_style names
NL.10：更应该使用underscore_style名称
NL.11: Make literals readable
NL.11：使字面值可读
NL.15: Use spaces sparingly
NL.15：谨慎使用空格
NL.16: Use a conventional class member declaration order
NL.16：使用常规的类成员声明顺序
NL.17: Use K&R-derived layout
NL.17：使用K＆R派生的布局
NL.18: Use C++-style declarator layout
NL.18：使用C ++风格的声明符布局
NL.19: Avoid names that are easily misread
NL.19：避免容易被误读的名称
NL.20: Don't place two statements on the same line
NL.20：不要在同一行上放置两个语句
NL.21: Declare one name (only) per declaration
NL.21：每个声明声明一个名称（仅）
NL.25: Don't use void as an argument type
NL.25：请勿将void用作参数类型
NL.26: Use conventional const notation
NL.26：使用传统的表示法
Most of these rules are aesthetic and programmers hold strong opinions. IDEs also tend to have defaults and a range of alternatives. These rules are suggested defaults to follow unless you have reasons not to.
这些规则大多数关于代码美观的，程序员持有强烈的观点。IDE也倾向于具有默认值和一系列替代方法。除非您有理由不这么做，否则建议遵循以下规则。
We have had comments to the effect that naming and layout are so personal and/or arbitrary that we should not try to "legislate" them. We are not "legislating" (see the previous paragraph). However, we have had many requests for a set of naming and layout conventions to use when there are no external constraints.
我们已经表示过，命名和布局非常具有个性和任意性，以至于我们不应试图“立法”它们。我们不是在“立法”（见上一段）。但是，在不存在为外部约束时，我们对一组命名和布局约定有很多需求。
More specific and detailed rules are easier to enforce.
更具体，更详细的规则更易于执行。
These rules bear a strong resemblance to the recommendations in the PPP Style Guide written in support of Stroustrup's Programming: Principles and Practice using C++.
这些规则与为支持Stroustrup的《 Programming：使用C ++的原理和实践》而编写的PPP样式指南中的建议非常相似。
关注微信公众号【面向对象思考】轻松学习每一天！
面向对象开发，面向对象思考！
