C++核心准则​NL：命名和布局规则

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样式指南中的建议非常相似。

原文链接

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#nl-naming-and-layout-rules

新书介绍

《实战Python设计模式》是作者最近出版的新书，拜托多多关注！

本书利用Python 的标准GUI 工具包tkinter，通过可执行的示例对23 个设计模式逐个进行说明。这样一方面可以使读者了解真实的软件开发工作中每个设计模式的运用场景和想要解决的问题；另一方面通过对这些问题的解决过程进行说明，让读者明白在编写代码时如何判断使用设计模式的利弊，并合理运用设计模式。

对设计模式感兴趣而且希望随学随用的读者通过本书可以快速跨越从理解到运用的门槛；希望学习Python GUI 编程的读者可以将本书中的示例作为设计和开发的参考；使用Python 语言进行图像分析、数据处理工作的读者可以直接以本书中的示例为基础，迅速构建自己的系统架构。

---

觉得本文有帮助？请分享给更多人。

关注微信公众号【面向对象思考】轻松学习每一天！

面向对象开发，面向对象思考！