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