为即将推出的C ++项目提出了以下建议。
还有其他选择吗？或者上面的列表应该在C ++项目中使用什么？
一些相关链接
答案 0 :(得分：9)
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices（C ++深度系列） 作者：Herb Sutter和Andrei Alexandrescu。
答案 1 :(得分：7)
我真的认为你选择哪一个并不重要，只要每个人都同意它。有时这可能很难，因为似乎有些风格不符合人们的情况。即它归结为争论所有成员变量前缀m_是否漂亮。
我一直在使用和修改Geosoft标准，这些标准适用于C ++。 what-is-your-favorite-coding-guidelines-checklist线程
还有其他一些答案 2 :(得分：5)
答案 3 :(得分：5)
答案 4 :(得分：3)
试试这个，这是美国宇航局戈达德太空飞行中心使用的那个。
答案 5 :(得分：3)
我为一家大型英国公司编写了一个编码标准，并且非常清楚地说明了为什么我选择了某些东西而不仅仅是为了让它成为一堆“你应该”的声明。 （ - ：
作为快速解决方法，我建议强制执行：
答案 6 :(得分：3)
编码标准只有在帮助您编写代码时才有意义。因此，他们只需要保持代码的一致性（即如果有人将m_表示为变量成员而某些人没有，则可能需要更长的时间来查看代码，而不是使用相同的样式）。
这就是他们应该做的所有事情，所以只需拿起你现有的代码，确保你的团队代码采用相同的风格。
我喜欢把它想象成卡通片。如果你成为辛普森一家的漫画家，你必须以官方的方式画眼睛，或者一切看起来都是裤子，但是如果你去找Family Guy，你必须以不同的方式画画。这两种方式都不对。
太多的标准都是关于无意义的限制，这些限制是由那些不编码自己的人写的（或者认为自己太好了，不能保留它们）。其他人试图教你如何编码。它们都没有良好的标准，只是让你更容易看到一些代码并理解它的作用。
例如。我的标准包括命名目录的规则 - 你将始终将你的代码放在一个名为与项目相同名称的目录中，所有二进制文件都在bin子目录中，所有配置文件都在同一个地方，并且更改日志等等。简单的东西，但我保证我永远不会在根目录中找到一个与其二进制文件不同的项目，我不知道对它做了哪些更改。简单易用的东西会带来巨大的变化。
答案 7 :(得分：2)
我同意Harald Scheirich的观点，让团队就规则应该达成一致意见是最重要的，而不仅仅是挑选一个外界推荐的一套。
我个人的建议是阅读Steve McConnell撰写的Code Complete, 2nd Edition，其中描述了（在许多其他有用的东西中）几种常见的编码标准，并对每种标准提供评论。这可能有助于您的团队制定自己的标准。
答案 8 :(得分：2)
洛克希德·马丁公司的JSF飞行器C ++编码标准是一个有趣的阅读，但它有点矫枉过正，除非你在一个bug可以杀死人的领域工作。从计算机伦理的角度来看，这仍然是一个非常重要的例子，关于如何将安全性和正确性作为首要任务进行编程的例子。
对于通用C ++编码，我个人推荐Herb Sutter的 C ++编码标准。从一开始，它强调标准化的 not （与风格或偏好相关的事物，而不是促进安全性，正确性和效率的实践）。它也是列表中最容易阅读的内容之一，为每个标准提供了非常简洁但简洁的论据，使您可以轻松地向同事展示。
答案 9 :(得分：1)
答案 10 :(得分：1)