我正在为大约15个开发人员组成的团队编写一个编码标准文档，每年的项目负载在10到15个项目之间。在其他部分中(我可能会在这里发布)，我正在编写有关代码格式的部分。因此，首先，我认为出于某种原因，我们建立一些基本的，一致的代码格式/命名标准是明智的。

在过去三年中，我查看了该团队撰写的大约10个项目，很显然，我发现了各种各样的样式。承包商有时进进出出，有时甚至使团队规模扩大一倍。

我正在寻找有关代码格式化和命名标准的一些建议，这些建议确实奏效了……但也可以说是合理的。我认为一致性和共享模式在使代码更具可维护性方面大有帮助...但是，在定义所述标准时我还应该考虑其他事项吗？

• 我们如何阵容括号？在处理类，方法，尝试catch块，switch语句，if else块等时，是否遵循相同的括号准则。
• 我们是否在列上排列字段？我们是否用下划线标记/前缀私有变量？我们是否遵循任何命名约定，以便更轻松地在文件中查找细节？我们如何订购班级成员？

关于名称空间，打包或者源代码文件夹/组织标准的建议呢？我倾向于从以下内容开始：

<com|org|...>.<company>.<app>.<layer>.<function>.ClassName

我很想知道在我冒险提出这些标准之前，是否还有其他比我习惯的做法更被人们接受的做法。链接到已经在线发布的标准也很不错-尽管我已经做了一些。

解决方案

回答

很明显，它取决于语言和技术。从示例名称空间的外观来看，我将猜测Java，在这种情况下，http：//java.sun.com/docs/codeconv/是一个很好的起点。我们可能还希望查看类似maven的标准目录结构的内容，这将使所有项目看起来相似。

回答

首先找到一种与语言配合使用的自动代码格式化程序。原因：无论文件说什么，人们都会不可避免地违反规则。通过格式化程序运行代码比在代码审查中随意挑选要容易得多。

如果我们使用具有现有标准的语言(例如Java，C＃)，则最容易使用它，或者至少首先将其作为初稿。 Sun对其格式设置规则考虑了很多；我们最好利用它。

无论如何，请记住，许多研究表明，诸如括号位置和空格使用之类的各种变化对生产率，易理解性或者错误的普遍性没有可测量的影响。拥有任何标准是关键。

回答

我要提第二个杰森的建议。

我刚刚为一个10-12的团队完成了一份标准文档，该文档主要在perl中工作。该文件称对复杂的数据结构使用"像perltidy一样的缩进"。我们还为每个人提供了示例性的设置，这些设置将清理其代码以符合此标准。语言非常清晰，而且非常符合行业标准，因此我们团队对此予以了很大的认可。

着手编写此文档时，我在存储库中询问了一些出色的代码示例，并在Google上搜索了一些比我更聪明的架构师来构建模板的标准文档。在不进入微观管理者领域的情况下，很难做到简洁，务实，但这是非常值得的。具有任何标准确实是关键。

希望能解决！

回答

来自汽车行业，出于具体原因，这里使用了一些样式标准：

始终在控制结构中使用大括号，并将其放置在单独的行上。这消除了人们添加代码以及是否在控制结构中错误地包含或者不包含代码的问题。

if(...)
{

}

所有开关/选择都有默认情况。如果不是有效路径，则默认情况下会记录错误。

由于与上述相同的原因，任何if ... elseif ...控件结构都必须以默认值结尾，否则，如果它不是有效路径，它也会记录错误。单个if语句不需要这样做。

在偶尔有回路或者控制结构为空的情况下，总是在其中插入分号以表明这是有意的。

while(stillwaiting())
{
   ;
}

命名标准对于typedef，定义的常量，模块全局变量等具有非常不同的样式。变量名称包括类型。我们可以查看名称，并对它属于哪个模块，其范围和类型有一个很好的了解。这使得检测与类型等相关的错误变得容易。

还有其他人，但是这些都是我无法承受的。

-亚当