我们将在我们的团队中开始一个新项目,该团队由不到10名开发人员组成。 我们可以访问现代IDE,例如VS2010。
该项目非常动态(用户的需求变化非常快)和跨平台。因此,我需要一个高度可读和非常详细的 C ++编码标准,以便新开发人员可以在将来轻松更改旧代码。我还需要不要编写列表,所以代码将在不同的操作系统(至少是Windows和Linux)上编译。
答案 0 :(得分:7)
编码标准仍然是一个问题,因为每个人都暗中认为他们可以用一个非常聪明的编码标准解决所有世界的编程问题。然后迫使程序员遵循它们。 (非常像编程程序员。)
不幸的是,很少有编码标准可以解决复杂项目中的重要问题,如:
相反,大多数编码标准都解决了琐事:
至于主要问题,除了设计和实施代码之外,我不知道任何其他工程师会引以为傲的详细标准。
答案 1 :(得分:2)
阅读C++ Coding Standards。这不是大多数人所谓的编码标准文档,但您可能想要阅读它。第一个指南之一是不要膨胀小东西(不要过分强调细节:专注于影响语义的规则而不是语法,如更喜欢RAII而非原始指针而不是在任何地方添加大括号,在它自己的行中并缩进3个空格)
答案 2 :(得分:1)
就编码标准而言,在大多数情况下,只要它们牢固到位,具体编码标准就不那么重要了。标签与空间?谁在乎。选择一个并继续使用它。与条件线或下一条线在同一条线上的卷曲括号?谁在乎。选择一个并保持一致。
我个人喜欢Linux内核编码标准。
http://www.kernel.org/doc/Documentation/CodingStyle
它适用于C而不是C ++,但它可能是开始项目标准的好地方。不幸的是,我怀疑它提供了“不写”列表的建议。
答案 3 :(得分:0)
我强烈推荐Google style guide,自两年前实习以来,我一直没有停止使用。上面的链接详细列举了规则,以及每个规则在优缺点方面的理由。
它确实具有高可读性和非常详细,但重要的规则(一直出现的规则)很少且易于记忆。他们通过为我的命名和函数参数传递约定提供一致性,真正简化了我的C ++编码。
我知道您正在使用IDE,但emacs用户可以使用他们的“google.el”文件进行自动格式化。还有一个强大的“cpplint”脚本,它运行在源文件中,以与gcc使用的相同警告格式打印样式违规。这使您可以在签入文件之前快速修复样式违规。如果您的IDE可以解析gcc警告并从警告跳转到源文件中的警告,那么修复此类违规将变得非常容易。 Emacs和Eclipse CDT就像其他编辑器/ IDE一样。