已为即将到来的C ++项目提出了以下建议。

• S ++和Alexandrescu撰写的C ++编码标准
• JSF航空器C ++编码标准
• C ++风格的要素
• 有效的C ++第三版，作者：斯科特·迈耶斯(Scott Meyers)

还有其他选择吗？还是上面的列表应在C ++项目上使用？

一些相关链接

• 我们认为软件公司应该给开发人员施加编码风格吗？
• https://stackoverflow.com/questions/66268/what-is-the-best-cc-coding-style-closed

解决方案

嗯，奇怪的问题。只需选择大多数团队成员都熟悉的标准即可。为团队做一些民意测验。不确定SO可以如何:)

试试这个，这是美国宇航局戈达德太空飞行中心使用的那个。

http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.3.pdf

我真的认为，只要每个人都接受它，那么采用哪一个都没有关系。有时这可能很难，因为某些样式似乎与人们的风格不一致。 IE。归结为关于用" m_"为所有成员变量加前缀是否漂亮的争论。

一段时间以来，我一直在使用和修改Geosoft标准，这些标准是针对C ++的。什么是我们最喜欢的编码指南清单清单中的其他内容

我已经为一家大型英国公司编写了编码标准，并且非常清楚地说明了我选择某些东西的原因，而不仅仅是将其变成一堆" Thou shalt"的声明。 (-：

作为一种快速的解决方法，我建议我们强制执行以下操作：

• 斯科特·迈耶斯(Scott Meyers)的《有效C ++第三版》(亚马逊链接)-如果我们可以找到本书第一版的副本，则可以购买该书作为OO设计的概述，该产品已从更高版本中删除。 )-：
• 斯科特·迈耶(Scott Meyer)的书《有效的STL》(Amazon链接)-必须使用STL才能有效地使用C ++。
• 史蒂夫·麦康奈尔(Steve McConnell)的书《代码完整2》(Amazon链接)-不是特定于C ++的，而是充满了深刻的见解。

编码标准只有在编写代码时才有意义。因此，他们只需要保持代码一致即可(即，如果有人将m_用作变量成员，而有人没有将m_用作变量成员，则比他们都使用相同样式的代码要花更长的时间)。

这就是他们(应该)要做的，所以只需选取我们现有的代码，并确保团队代码使用相同的样式。

我喜欢把它像卡通一样。如果我们成为《辛普森一家》的漫画家，则必须以正式的方式来吸引别人的目光，否则一切看上去都像裤子一样，但是如果我们去找《家庭伙伴》，我们就必须以不同的方式来吸引他们。两种方法都不对。

太多的标准是关于无意义的限制，这些限制是由没有编写自己代码的人(或者认为自己太过优秀以至于无法遵守)的人编写的。其他人试图教你如何编码。它们都没有在一个好的标准中占有一席之地，它们只是使我们更容易查看一些代码并了解其功能。

例如。我的标准包括命名目录的规则，我们将始终将代码放在与项目同名的目录中，所有二进制文件都放入bin子目录中，所有配置文件都位于同一位置，以及changelog等。所有这些都非常简单的东西，但我保证我永远不会在根目录中找到一个名为二进制文件的项目，而我不知道对该项目进行了哪些更改。简单，容易的东西会带来很大的不同。

C ++编码标准：101条规则，指南和最佳实践(C ++深度系列)
赫伯·萨特(Herb Sutter)和安德烈·亚历山大(Andrei Alexandrescu)。

我同意Harald Scheirich的观点，最重要的是让团队就应该遵循的规则达成共识，而不是仅仅挑选局外人推荐的规则。

我个人的建议是阅读Steve McConnell撰写的Code Complete，第二版，它描述了(在很多其他有用的东西中)几种通用的编码标准，并对每个标准进行了注释。这可能会帮助团队建立自己的标准。

高完整性C ++编码标准手册版本2.4

Poco C ++编码样式指南.pdf