对于即将到来的C++项目，已经提出了以下内容。

• C++编码标准，由萨特和Alexandrescu
• JSF飞行器C++编码标准
• C++风格的元素
• 有效的C++第三版，由Scott Meyers

还有其他选择吗？或者上面的列表在C++项目中应该使用什么？

一些相关链接

• 你认为软件公司应该强制开发人员使用编码风格吗？
• https://stackoverflow.com/questions/66268/what-is-the-best-cc-coding-style-closed

C++编码标准：101条规则、准则和最佳实践(深度系列中的C++)赫伯·萨特和安德烈·亚历山大·埃斯库。

我真的认为你采用哪一种并不重要，只要每个人都同意。有时这可能很难，因为有些风格似乎不符合人们的口味。也就是说，它归根结底是在讨论是否用m_作为所有成员变量的前缀是漂亮的。

我已经使用和修改GEOSOFT标准有一段时间了，这些都是针对C++的。在您最喜欢的编码指南检查表线程中还有其他一些。

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

嗯，奇怪的问题。只需选择大多数团队成员熟悉的标准。为你的团队做一些投票。不知道这有什么帮助：)

编码标准只有在帮助您编写代码时才有意义。因此，他们只需要保持代码的一致性(例如，如果有人将m ou用于变量成员，而有人不将m ou用于变量成员，则摸索代码的时间可能比使用相同样式的代码要长)。

这就是他们应该做的，所以只需拿起你现有的代码，并确保你的团队代码是相同的样式。

我喜欢把它想象成动画片。如果你成为《辛普森一家》的漫画家，你必须以官方的方式来吸引眼球，否则一切看起来都像裤子，但是如果你去找一个家庭成员，你必须以不同的方式来吸引他们。两种方法都不对。

太多的标准都是关于无意义的限制，这些限制是由那些没有自己编码的人(或者认为自己太好而无法遵守这些标准)编写的。其他人试图教你如何编码。它在一个好的标准中也没有位置，这些标准只是让您更容易地查看一些代码并理解它在做什么。

我的标准包括命名目录的规则——你总是把你的代码放在一个与项目同名的目录中，所有二进制文件都放在bin子目录中，所有配置文件都放在同一个地方，以及一个changelog等等。这些都很简单，但我保证在根目录，我不知道对它做了什么更改。简单、简单的东西会产生巨大的影响。

我已经为一家英国大公司写了一个编码标准，并且非常清楚为什么我选择了某些东西，而不是仅仅把它变成一堆"你应该"的声明。(-)

作为一个快速的出路，我建议强制：

• Scott Meyers的有效C++第三版(亚马逊链接)-如果你能找到这本书的第一版的拷贝，然后购买它的OO设计的概述，从后来的版本中删除。-
• Scott Meyer的书有效的STL(Amazon Link)-你必须使用STL有效地使用C++。
• Steve McConnell的图书代码完成2(亚马逊链接)-不是C++特定的，但充满了深刻的见解。

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

http://software.gsfc.nasa.gov/assetsapproved/pa2.4.1.3.pdf

洛克希德马丁公司的JSF飞行器C++编码标准是一个有趣的读物，但如果你在一个bug可以杀死人的领域工作，那就有点过火了。从计算机伦理学的角度来看，它仍然是一个非常重要的例子，关于如何以安全性和正确性为首要任务进行编程的例子。

对于通用C++编码，我个人推荐萨特的C++编码标准。从一开始，它就强调了不需要标准化的内容(与风格或偏好相关的内容，而不是促进安全、正确性和效率的实践)。它也是列表中最容易阅读的内容之一，为每个标准提供非常简短但简明的论据，使您的同事很容易看到它。

我同意Harald Scheirich的观点，最重要的是让团队就规则应该是什么达成一致，而不仅仅是选择一个外界推荐的集合。

我个人的建议是阅读Steve McConnell编写的第二版完整的代码，它描述了(以及其他许多有用的东西)几种常见的编码标准，并对每种标准进行了评论。这可能有助于您的团队建立自己的标准。

• 苹果可可编码指南

• GNU编码标准

• 贝尔实验室推荐的C样式和编码标准

• 来自posix/iso的保留名称

• Facebook hhvm编码约定

• GEOSOFT C++编程风格指南

• LLVM编码标准

• SUNOS的C样式和编码标准

PoC+C++编码风格指南