Standards Document我正在为大约15个开发人员组成的团队编写一个编码标准文档，每年的项目负载在10到15个项目之间。在其他部分中(我可能会在这里发布)，我正在编写有关代码格式的部分。因此，首先，我认为出于某种原因，我们建立一些基本的，一致的代码格式化/命名标准是明智的。 在过去的三年中，我查看了该团队撰写的大约10个项目，很显然，我发现了各种各样的样式。承包商有时进进出出，有时甚至使团队规模扩大一倍。 我正在寻找有关代码格式化和命名标准的一些建议，这些建议确实奏效了……但也可以说是合理的。我认为一致性和共享模式在使代码更具可维护性方面大有帮助...但是，在定义所述标准时我还应该考虑其他事项吗？
关于名称空间，打包或源代码文件夹/组织标准的建议呢？我倾向于从以下内容开始：
我很想知道是否还有其他比我习惯的方法更能被接受的方法，然后再冒险提出这些标准。链接到已经在线发布的标准也很不错-即使我已经做了一些。 来自汽车行业，出于某些具体原因，这里使用了一些样式标准： 始终在控制结构中使用大括号，并将其放在单独的行上。这消除了人们添加代码以及是否在控制结构中错误地包含或不包含代码的问题。
所有开关/选择都有默认情况。如果不是有效路径，则默认情况下会记录错误。 由于与上述相同的原因，任何if ... elseif ...控制结构都必须以默认值结尾，否则，如果它不是有效路径，它也会记录错误。单个if语句不需要这样做。 在偶尔有回路或控制结构为空的情况下，总是在其中插入分号表示这是有意的。
命名标准的类型定义，定义的常量，模块全局变量等的样式非常不同。变量名称包括类型。您可以查看名称，并对它所属的模块，范围和类型有个很好的了解。这使得检测与类型等相关的错误变得容易。 还有其他人，但是这些都是我无法承受的。 -亚当 首先找到一种与您的语言配合使用的自动代码格式化程序。原因：无论文件说什么，人们都会不可避免地违反规则。通过格式化程序运行代码比在代码审查中随意挑选要容易得多。 如果您使用的是具有现有标准的语言(例如Java，C＃)，则最容易使用它，或者至少首先将其作为初稿。 Sun对其格式设置规则考虑了很多；您最好利用它。 无论如何，请记住，许多研究表明，诸如括号位置和空格使用之类的各种变化对生产率，易理解性或错误的普遍性没有可测量的影响。拥有任何标准是关键。 我要提第二个杰森的建议。 我刚刚为一个10-12的团队完成了一份标准文档，该文档主要在perl中工作。该文件称对复杂的数据结构使用"像perltidy一样的缩进"。我们还为每个人提供了示例性的设置，这些设置将清理其代码以符合此标准。这是非常清晰的语言，并且非常符合该行业的标准，因此我们团队对此予以了很大的认可。 着手编写此文档时，我在我们的存储库中询问了一些出色的代码示例，并在Google上搜索了一些比我更聪明的架构师来构建模板的标准文档。在不进入微观管理者领域的情况下，很难做到简洁，务实，但这是非常值得的。具有任何标准确实是关键。 希望能解决！ 很明显，它取决于语言和技术。从您的示例名称空间的外观来看，我将猜测Java，在这种情况下，http：//java.sun.com/docs/codeconv/是一个很好的起点。您可能还希望查看类似maven的标准目录结构的内容，这将使您的所有项目看起来都相似。 |
