基于现代IDE的小群体C++编码标准

编码标准仍然是一个问题,因为每个人都暗自认为他们可以用一个非常聪明的编码标准来解决世界上所有的编程问题。然后强迫程序员跟随它们。(很像编程程序员。)

不幸的是,很少有编码标准能够解决复杂项目中的问题,比如:

• 如何清晰有效地划分和建模问题
• 程序分区如何最好地与其他分区交互
• 如何编写逻辑解释(“注释”)来解释代码

相反,大多数编码标准都涉及如下琐事:

• 缩进和大括号样式
• 评论是否应该出现
• 构造标识符的机械规则
• 对一行中的字符、参数数目等进行任意限制。

关于主要问题,除了 设计和实现其他工程师引以为豪的代码。

读 C++ Coding Standards . 这不是大多数人所说的编码标准文档,但您可能想阅读它。第一个指南之一是 不要使小东西膨胀 (不要过于强调细节:关注影响语义的规则,而不是语法,如 喜欢RAII而不是原始指针 而不是 在每一处添加大括号,在它自己的行中并缩进3个空格 )

就编码标准而言,在大多数情况下,只要特定的编码标准牢固就位,它们就不那么重要了。标签与空间?谁在乎。选择一个,然后跟着它走。大括号与条件或下一行在同一行?谁在乎。选择一个并保持一致。

我个人喜欢Linux内核编码标准。

http://www.kernel.org/doc/Documentation/CodingStyle

这是C,而不是C++,但它可能是一个很好的地方开始对你的项目的标准。不幸的是,我怀疑它提供了关于“不写”列表的建议。

我强烈推荐 Google style guide 自从两年前在那里实习以来,我一直在使用它。上面的链接详细列举了规则,以及每个规则的优缺点。

它确实可读性很强,而且非常详细,但是重要的规则(总是出现的规则)很少,而且很容易记住。通过给我的命名和函数参数传递约定提供一致性,它们确实简化了我的C++代码。

我知道你在使用一个IDE,但是emacs用户可以使用他们的“google.el”文件来自动格式化。还有一个强大的“cpplin”脚本,它运行在源文件中,以与gcc使用的相同警告格式打印样式冲突。这样可以在签入文件之前快速修复样式冲突。如果您的IDE可以解析gcc警告,并在源文件中从警告跳转到警告,那么修复此类冲突就变得非常简单。Emacs和EclipseCDT可以做到这一点,其他编辑器/IDE也是如此。