为即将到来的 C++ 项目提出了以下建议。
还有其他选择吗？还是上面的列表应该在 C++ 项目中使用？
一些相关链接
【问题讨论】：
标签： c++ coding-style documentation standards
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices（C++ 深度系列） 作者：Herb Sutter 和 Andrei Alexandrescu。
【讨论】：
我真的认为你采用哪一个并不重要，只要每个人都同意它。有时这可能很难，因为某些风格似乎不符合人们的口味。 IE。归根结底是争论在所有成员变量前加上m_ 是否是漂亮。
我一直在使用和修改Geosoft 标准，这些是针对 C++ 的。 what-is-your-favorite-coding-guidelines-checklist 线程中还有一些其他的
【讨论】：
嗯，奇怪的问题。只需选择大多数团队成员都熟悉的标准。为您的团队进行某种民意调查。不确定 SO 在这里如何提供帮助:)
【讨论】：
【讨论】：
试试这个，它是美国宇航局戈达德太空飞行中心使用的那个。
【讨论】：
我为一家大型英国公司编写了一个编码标准，并且非常清楚我选择某些东西的原因，而不是仅仅把它变成一堆“你应该”的声明。 (-:
作为一种快速的出路，我建议强制：
【讨论】：
编码标准只有在帮助您编写代码时才有意义。所以他们只需要保持你的代码一致（即，如果有人将 m_ 用于变量成员而有人没有，那么与他们都使用相同的样式相比，理解代码可能需要更长的时间）。
这就是他们（应该）做的所有事情，所以只需选择您现有的代码并确保您的团队代码风格相同。
我喜欢把它想象成卡通片。如果你成为辛普森一家的漫画家，你必须以官方的方式画眼睛，否则一切都看起来很裤子，但如果你去 Family Guy，你必须以不同的方式画它们。两种方式都没有错。
太多的标准是关于无意义的限制，由不自己编码（或认为自己太好以至于无法遵守）的人编写。其他人试图教你如何编码。两者都没有在一个好的标准中占有一席之地，这些只是让您更容易查看一些代码并理解它的作用。
例如。我的标准包括命名目录的规则 - 您将始终将代码放在与项目同名的目录中，所有二进制文件都放在 bin 子目录中，所有配置文件都在同一个地方，还有一个变更日志等。简单的东西，但我保证我永远不会在我不知道对其进行了哪些更改的根目录中找到一个与其二进制文件不同的项目。简单易行的东西会产生巨大的影响。
【讨论】：
我同意 Harald Scheirich 的观点，最重要的是让团队就规则应该是什么达成一致，而不是仅仅选择外人推荐的系列。
我个人的建议是阅读 Steve McConnell 的 Code Complete, 2nd Edition，它描述了（在许多其他有用的东西中）几种常见的编码标准并提供了对每个标准的评论。这可能有助于您的团队建立自己的标准。
【讨论】：
Lockheed Martin 的 JSF Air Vehicle C++ Coding Standards 是一本有趣的读物，但它有点矫枉过正，除非您工作的领域是错误会导致人员死亡。从计算机伦理的角度来看，它仍然是一个非常重要的例子，它是一个关于如何以安全和正确性为重中之重的编程示例。
对于通用 C++ 编码，我个人推荐 Herb Sutter 的 C++ 编码标准。从一开始，它就强调不要标准化的东西（与风格或偏好相关的东西，而不是促进安全、正确和效率的做法）。它也是您列表中最容易阅读的内容之一，为每个标准提供了非常简短但简洁的论据，便于向您的同事展示。
【讨论】：