您如何记录您的编码标准？

Question

您发现什么是发布编码标准的最佳方式？为什么？

Answer 1

我们使用代码来记录标准。这与高级/首席工程师的执法相结合，对我们来说非常有用。我们不维护实际文档的原因是因为我们发现没有人读取它并且它变得过时了。

恕我直言，只需要证明这一点就是显示样式/标准的现有代码。

轻装上阵！

Answer 2

如果您使用.NET进行开发。我建议使用StyleCop来检查你的构建。我还建议使用ReSharper和StyleCop插件。

使用ReSharper和StyleCop插件，在符合标准的代码下会出现红色的“波浪形”线条，而简单的鼠标就会解释原因。没有代码评论，没有doctian的文档。

在构建过程中使用StyleCop将确保所有签入的代码都符合标准。

Answer 3

在我看来，发布编码标准的唯一有效方法是将其集成到开发人员使用的ide中（例如eclipse或idea）。所以新代码将遵循开箱即用的标准，旧代码可以使用ide重新格式化。

只有少数开发人员会阅读编码标准，之后会有更少人使用它们......

Answer 4

如果您的意思是样式指南 - Word文档或PDF。国际海事组织，这是“一成不变”，但在每个项目的基础上（如果你看到一些不起作用的东西，修复它为下一个项目，特别是如果它在项目的后期，你有一吨遵循现有风格的代码。）

Answer 5

我们将它放在wiki上，并附带指向代码段的链接，这对此很有帮助。

然后，我们在Eclipse中设置了一个代码格式化程序，以尽可能地匹配此编码标准，尽管这对最佳实践编码方法无能为力。

Answer 6

当我负责设置编码标准时，我会尝试在互联网上找到一个适合我们需求并使用它的好的。我将采用它所带来的任何格式，通常是PDF或Word。

重新发明轮子是没有意义的 - 我也可以利用其他人的辛勤工作。

Answer 7

我认为最好的方法是使用Checkstyle来强制执行您的编码标准，并确保如果某些代码违反了checkstyle规则，则构建会失败。

然后使用代码审查和配对编程，以便青少年可以向老年人学习

您还可以设置维基页面。

Answer 8

我们已完成以下工作来记录我们的编码标准：

1. 用简单的文件写下来。此样式指南的基础是Sun Coding Conventions。
2. 配置Checkstyle和PMD以遵循这些编码约定，另外为Eclipse提供了一个默认工作区，其具有适合已定义的Checkstyle和PMD配置的正确配置。
3. 在我们的编码约定中增加了三章，解释了Checkstyle，PMD和Eclipse配置填充了样式指南的哪一部分，以便每个架构师都可以修改样式指南以及Checkstyle，PMD和Eclipse的配置。
4. 开发了一些插件，通过将Checkstyle和PMD与我们的插件一起安装，我们的Checkstyle和PMD定义的编码约定是默认的，易于选择。

我们认为，不仅要将其写下来，还要将其集成到开发环境中，这不仅有很大帮助。另一方面，我们只对Eclpise这样做，因为如果你想为地球上的每一个IDE做这件事，那就太多了。

Answer 9

我们使用以下内容：

1. 编辑器中的工具/插件（checkstyle，pmd，内部工具）
2. 构建时间检查会生成报告。
3. 维基用于记录代码审核评论
4. 从3开始，我们将“太过分”的内容重构为内部工具。

Answer 10

一个内部网站，SVN用于管理变更工作。团队随时可以使用“最新”。

Answer 11

当我管理一个小团队时，我们的“编码标准”是CVS上的一个包装脚本，当您检查它时，它会在您的代码上运行缩进（使用团队范围的rc文件）。

Answer 12

我通过以下方式记录代码标准：

• 来自最重要的一般风格的结构（如缩进，换行，括号，......）
• 到不太明显的细节（(或)之前/之后的空格）
• 代码示例
• 设置描述以配置eclipse代码格式化程序
• PROSA

Answer 13

对于初始过程，使用子标题准备的wiki可用于收集各种开发人员的意见。一旦收集了反馈，就可以对其进行整理并“发布”。

<强>更新

几年后，Google Docs现在可以作为一种维基。

Answer 14

我们从Word文档转移到了

，这些文档被证明是繁琐且容易过时的

• 带有标准和示例的Wiki页面
• 在CI过程中运行的自动编码标准验证工具

N.B。此外，我们还有一个客户在CI周期中不使用构建本身以外的任何东西。他们将规则保留在ReSharper中并对结果非常满意

Answer 15

如果您使用的是Eclipse，则可以使用格式化程序（Preferences-＆gt; Java-＆gt; Code Style-＆gt; Formatters）在保存源文件时自动格式化代码。我们只需在wiki上使用我们公司的格式化程序，每个人都将其导入Eclipse。

格式化程序的一个很酷的事情是你可以决定使用哪一个，这样你就可以拥有不同格式的不同项目。但是，我们通常只使用一种格式，因此我们的代码在所有项目中都是统一的。

Answer 16

代码指南是描述实践的公司范围的文档。它是可用的，必须严格遵守。

代码格式标准由团队（或项目）成员决定。对于我们的项目，它作为Resharper插件的一组设置保存在SVN中。

Answer 17

取决于具体情况：

我在一家只有三名开发人员的小公司工作。在那里，我们只是 说出来。如果对编码风格有疑问，这只不过是问你的合作开发者。过了一会儿，有人意识到，多次询问了相同的问题，并在我们的wiki中打开了编码标准页面。

今天我在一个小型研究实验室工作。在这个特定的领域，我们没有 正式编码标准。但是，当我们在团队中工作并定期进行配对时， 隐式编码标准似乎无处不在。

---

一些开发飞机制导系统的朋友，我知道 他们同意基于

的编码标准

• 安全和政府限制
• 质量保证部门的需求和输入
• 如果还有任何选择自由：来自开发者的输入

此编码标准已记录下来并由QA强制执行。

Answer 18

我们目前在Wiki中拥有编码标准，只有高级开发人员才有权编辑。然而，正如许多人已经说过的那样，在最初的几天之后没有人读到它。我们目前正在尝试将我们的编码标准放到.NET端的StyleCop上。 Delphi的东西有点难，因为我们没有像StyleCop这样的Delphi框架可供使用。

Answer 19

我尽一切努力让每个人都能轻松申请：

• 首先，团队中的每个人都应该同意应用它们
• 我分享了二手编辑器的设置（gvim，emacs ...）
• 我提供带有样板标题
的空源文件
• 我在单一上标准化了标准 参考表，没有显示 规则，但一段代码正确 格式化为标准化

Answer 20

我们的项目主要是在python中，所以我们基本上使用了Python Coding Guidelines，在这里和那里改变了我们不喜欢的内容，并将它们放在我们的Trac wiki上。它在首页上链接，以便开发人员知道在哪里找到它。到目前为止，它实际上已经做了相当不错的工作！