我们使用Eclipse的保存操作和格式化程序来管理代码风格。虽然我们有一个建议的标准，但实际上没有人去执行它，所以实际上代码的格式化和风格存在一些差异。

这对我来说有点麻烦，因为各种空格变化都被提交到SVN代码库作为更新...

为了解决这个问题，我们需要建立一个代码规范并强制执行。以下是一些解决方法：

1. 建立明确的代码规范：制定一份详细的代码规范文档，明确指出代码格式、命名规范、注释规范等。确保每个开发人员都清楚地知道代码应该如何编写和格式化。

2. 提供培训和教育：为所有开发人员提供培训和教育，使他们了解代码规范的重要性和好处。培训可以包括使用Eclipse的保存操作和格式化程序的方法，以及如何遵循代码规范。

3. 使用自动化工具：利用Eclipse的保存操作和格式化程序，可以自动对代码进行格式化和风格检查。这可以帮助开发人员在编写代码时自动遵循规范，并减少人为错误。

4. 代码审查：定期进行代码审查，确保代码符合规范。代码审查可以由开发团队中的其他成员或专门的代码审查人员来执行。审查过程中需要检查代码的格式、命名、注释等是否符合规范，并提出改进意见。

5. 引入版本控制机制：对于已经提交到SVN代码库中的代码，可以引入版本控制机制，通过代码回滚或修复来纠正不符合规范的代码。这可以确保代码库中的代码始终保持一致的格式和风格。

通过以上措施，我们可以建立并严格执行代码规范，确保所有开发人员在编写代码时都遵循统一的格式和风格。这将有助于提高代码的可读性、可维护性和可扩展性，减少团队协作时的问题和冲突，并提升整体开发效率。

我们是否有编码标准？如果有，如何执行？

在项目中，编码标准是有所不同的。

编码标准涵盖的内容有：代码（类、变量、方法、常量），SQL命名和格式约定。

每个人都遵循这些标准吗？

是的，每个新加入项目的人都可以被要求创建一个遵循组织编码约定的演示项目，然后进行审查。这个练习使开发人员在开始真正的工作之前感到轻松自在。

那么，你们有没有采取措施来确保每个人都遵循标准呢？

我们使用StyleCop和FxCop来确保他们被严格遵守。如果代码不符合组织的编码约定，它们会显示为警告/错误。

Visual Studio Team系统具有良好的代码分析和检入策略，这可以防止开发人员提交不符合标准的代码。

希望这能有所帮助。

谢谢，

Maulik Modi

有人在工作中遇到过编码规范几乎没有被遵守的情况，也有一些地方几乎能够执行规范，或者至少能够轻易地进行检查。

下面是一些建议：

- 最重要的是让大家都认同一致性比个人偏好的风格更重要。制定编码规范之前和之后都应该进行讨论，但是不允许任何人选择不遵守规范。

- 代码审查应该是强制性的，提交时的注释中应包含审查人的用户名。如果你使用的源代码管理工具足够强大，考虑不允许没有有效审查人姓名的提交。

- 应该有一份每个人都知道的文件，详细说明编码规范。如果有足够的细节，就不会有太多争论。

- 在可能的情况下，自动检查约定（通过Lint、CheckStyle、FXCop等），这样提交者和审查者都可以快速检查导入/使用指令的顺序、空白等。

好处有：

- 主要是一致性，如果让任何人都能够随时随地地理解代码库的任何部分，将会有更大的灵活性。

- 传播最佳实践，如果禁止使用公共字段、可变结构等，那么没有人会无意中在代码中引入定时炸弹。（至少在规范范围内没有定时炸弹。当然，并没有完美代码的编码规范）

编辑：我应该指出，在大公司工作时，编码规范可能是最重要的。我相信它们即使在小公司也是有帮助的，但在那种情况下，可能不需要太多围绕规范的流程。当所有开发人员彼此都互相认识并且都在同一地点时，这对助于工作非常有帮助。

你列出了优点，但也存在缺点。遵守严格的约定会降低处理不符合这些约定的代码的能力，例如第三方代码。此外，实施一套规范也会增加每个程序员的学习成本、开发时间和维护成本。

我同意第二个“缺点”，但不同意第一个。在内部保持一致性不会以任何方式阻碍我查看第三方代码。它不会削弱任何现有的能力，只是在查看自己的代码时更顺畅。

我当然同意你的观点，但是我发现为大公司制定一套规范要困难得多。我在一家大约有400名开发人员的公司工作，所以几乎不可能让每个人都接受一套规则。这使得实施变得困难。

布莱恩：你可以想象我们在谷歌的讨论，比那还多的工程师（而且我们个个都很有自己的见解……）。当然，你不需要让每个人都同意每个规则，只需要让他们同意应该有规则，然后尽量取悦尽可能多的人。