在工作中处理编码标准（我不是老板）

我在一个约10个开发人员的小团队中工作。我们根本没有编码标准。有些事情已经成为常态，但某些做事方式却完全不同。我最大的是缩进。有些使用制表符，有些使用空格，有些使用不同数量的空格，这会带来很大的问题。合并时，我经常遇到冲突，因为有人使用他们的IDE自动格式化，并且他们使用与我不同的字符来缩进。我不在乎我们使用哪个，我只希望我们所有人都使用相同的。

否则，我将打开一个文件，某些行与条件在同一行上有大括号，而其他行在下一行。再说一次，我不介意哪一个都一样。

我已经将标准的问题一对一地提交给我的直接经理，并在小组会议中提出来，而他对此并不过分担心（还有其他一些人与我有相同的看法）。我提出了关于缩进字符的具体问题，他认为更好的解决方案是“创建某种脚本，当我们从存储库中推入/拉出时可以转换所有内容。” 我怀疑他不想更改，而且此解决方案似乎过于复杂，容易出现维护问题（而且，这仅解决了较大问题的一种表现）。

你们中有人遇到过类似的情况吗？如果是这样，您如何处理？有什么好处可以帮助我按标准出售我的老板？在我们感兴趣的人当中，发起基层运动来创建编码标准是否是一个好主意？我是否太过挑剔，应该放手吗？

谢谢大家的时间。

注意：谢谢大家到目前为止的宝贵反馈！明确地说，我不想规定一种风格来统治所有人。我愿意放弃自己喜欢的做事方式，而选择最适合每个人的方式。我希望保持一致，我希望这是一个民主国家。我希望这是每个人都同意的集体决定。是的，并不是每个人都能如愿以偿，但我希望每个人都能够成熟到足以妥协以改善团队的能力。

注意2：有些人被我上面给出的两个示例所困扰。我更关心这件事。它以许多示例体现出来：命名约定，应该被分解的巨大功能，在util或service中使用某些东西，应该是常量还是注入的东西，我们都应该使用不同版本的依赖项还是相同的版本，接口用于这种情况，应如何设置单元测试，应如何进行单元测试（特定于Java），如果我们使用批注或外部配置。我可以继续。

当我们第一次加入时，我和我的同事在团队中也遇到类似的问题（我先加入团队，大约一年后他加入了团队）。没有真正的代码标准。我们是一家MS商店，甚至没有使用MS编码标准。我们决定以身作则。我们坐在一起，起草了一份包含我们所有标准的文档：IDE标准，命名标准以及我们能想到的一切。然后，他和我同意明确遵循该标准。我向团队发送了一封电子邮件（来自我们俩），并通知他们我们发现了一个缺失，我们将用我们的文档解决该缺失。我们邀请了批评，想法，评论，意见。我们收到的反馈信息很少，只有一点点回推。他和我立即开始使用这些标准，当我们将初级开发人员引入我们的项目时，我们向他们介绍了该标准并开始使用它。我们有一些潜在客户，起初并不愿意，但已慢慢开始将标准用于很多方面。

我们发现许多初级开发人员已经认识到相同的问题，但是正在等待其他人加紧做出决定。一旦有计划可循，许多人便渴望采用它。那些不愿意通过任何其他方式进行编码的人很难破解，从长远来看，它们通常会将自己编码在图片之外。

如果您需要标准，请开拓道路。提出建议的标准列表，您认为这些标准将使您的团队受益。提交给同龄人并领导反馈。我敢肯定，您团队中的其他人也有类似的想法，但是他们可能不愿意为此做任何事情。正如甘地所说：“您必须是世界上希望看到的改变。”

标准不应该由经理定义和执行。整个团队应该同意标准。如果他们不能就一套通用的标准达成共识，那么让经理强制将标准强加于他们将会失败。

您和其他同意您的人应该以身作则。开始使用相同的编码标准，将其发布，并将其推广到团队的其他成员，并请您提供有关如何改进它们的反馈。

这是尝试提升标准时的重要一点：确保重点不在寻找最佳的做事方式，而在于寻找一致的做事方式。就像某些人可能会不同意的那样，没有一种真正的括号样式，一种真正的注释样式等等。使代码更易于阅读（因而更易于维护）的是一种一致的样式，无论它是什么。

您能显示出由于造成问题而浪费时间的一些证据吗？

如果您花费大量时间来解决这些问题，或者导致需要一定时间修复的错误，那么通过采用编码标准可以大幅度降低这一成本。

因此，请记录您遇到的问题以及解决这些问题所花费的时间-对您和您（在您意识到这些问题的情况下）您的同事。

然后，当您有足够数量的数据时，将其提供给您的同事。他们应该看到采用标准的好处。如果没有显示数据给您的老板和他的老板。表明拥有编码标准可以为您的公司省钱，并且他们应该支持您采用它们。

在您的特定情况下，我认为您老板的解决方案是一个很好的解决方案。无需更改他们在整个职业生涯中所做的事情，这没关系，因为只要代码可读性强，编译器忽略的代码样式就无关紧要。如果每个人都在签出时对样式进行自动格式化，而在签入时对标准样式进行自动格式化，那么一切都会很好。（可悲的是，我建议在我工作的地方提出反对，理由是编码人员将不再编写与连续集成服务器所见相同的确切代码。）

我认为编码标准适用于对代码质量产生真正影响的地方：例如，较小的方法，承担明确责任的类，对较难理解的部分进行有用且准确的注释等。不幸的是，这些方面很难自动检查，但这是软件开发的基础。您真正能做的就是教别人好的做法，并教自己用错误的大括号读代码。

关于编码标准：我将与几乎所有其他人一起讨论编码标准是“好事”（相对于没有标准）。

但是，不要被带走。我参与了一些项目，这些项目规定了特定的缩进样式，一直到字符数（当项目做得那么远时，他们不可避免地会选择8位缩进之类的愚蠢东西）。不要汗流stuff背。

一个简单的解决方案：为开发人员提供一些大括号和缩进的选择，但要指出大括号的样式和缩进在整个模块中必须保持一致。（您确实希望foo.h和foo.cpp遵循相同的样式，不是吗？）维护者必须适应现有的样式；他们无法重写模块以适应其异想天开的风格。一个模块中的多种样式只是令人困惑，是草率的标志。当我看到那胡说八道时，我不知道还有什么不对劲。

您可能还需要考虑禁止在文件的已保存内容中使用选项卡进行缩进。大多数IDE /编辑器都将用户输入的选项卡转换为空格，工作做得很合理，并且大多数选项使自动转换成为可能。当文件已经包含制表符时，尤其是混合使用制表符和空格时，许多人会做得很糟糕。

综上所述，我认为您的项目可能存在更深层次的问题。您提到了合并问题。如果您发现自己需要进行大量合并，则可能表明该项目的分区不正确。就像太多的厨师宠坏了汤一样，在同一文件上操作的太多程序员也破坏了项目。为什么乔，苏西和你们每个人都触摸foo.cpp？

这是进行一些研究的领域之一。基本上，主要问题是您是否正在执行代码审查。毫无疑问，代码审查是提高代码质量的最有效方法。（来源：CMU软件工程学院）。它肯定比额外的测试器更有效。

现在，代码审查受益于通用的编码标准，因为这使得阅读其他人的代码更加容易。这为您提供了两步来介绍编码标准的论点：最后，它确实使生成良好的代码便宜。

既然已经有“几个其他人”与您在一起，我建议您临时开会。邀请所有开发人员，花一小段时间，弄清楚每天有什么事情困扰着您自己和您的同事。不要试图找到第一个具体的解决方案，只是弄清楚什么需求，你是目前所有写代码的方式发生变化。

然后，看看大家是否都可以同意一些基本概念。在@David Hammen提出的每个模块中使用相同样式的建议是一个不错的开始，我认为大多数开发人员都可以同意。

如果您一down而就，就可以在编写新代码时就某种基本风格达成共识，那将是一个很好的补充。专注于实际上会影响可维护性的事物；命名问题在我的个人列表中会占据很高的位置，因为如果您在单个产品中有六种不同的命名样式，而这些样式的复杂性却很明显，它将很快变得令人头疼，但是请再次注意您和您的团队认为重要的事情。起草一份简短的文件，每个人至少可以同意遵循（即使他们自己可能具有不同的宠物风格）并将其邮寄给团队中的每个人。使它成为“有生命的”文档，确保随时间进行更新，但请确保不要过于僵化和具体化。

除非您的老板参与编写代码，否则他不必过多担心采用哪种确切的样式（前提是该样式集中于可读性和可维护性），但是他应该能够看到遵循相同样式的团队中每个人的收益。编写代码时。

有些事情很痛苦。最痛苦的是自动格式化代码的IDE，再加上以不同方式设置其IDE的开发人员。每次比较代码时，具有不同设置的人对代码进行编辑后，您都会进行一百次更改。那是不可接受的。在这里，您需要团结所有人的头脑，商定一组设置，并拒绝使用不同设置的任何人进行的签入。如果更改一行代码，则差异应显示更改的一行代码，而不是数百行。

其他一切都无害，或者有更好的方式去做别人可以说服的事情。这里的规则应该是：除非您真正进行了改进，否则不要与他人的代码混淆。而且样式A和样式B的混合总是比样式A或样式B都差。

确保遵循最佳实践。每种语言都不同。但是您不需要那里的标准（这些标准可能是由一个善意的人编写的，但实际上并不是那么博学），但是每个人都应该尝试给出良好的例子。

绝对避免权力斗争。没有什么比您的团队中希特勒试图强迫所有人遵守他的意愿更糟了。不幸的是，那个愿意自愿编写您的编码标准的人:-(

您提供的所有示例基本上都是关于空格和格式的。如果这是最大的问题，我有点同意您的经理的意见：这没什么大不了的。

标准真正有用的地方在于命名事物和降低复杂性。如何命名标识符，类，放置它们的位置等。保持名称的一致性非常重要，尤其是在大型项目中。降低复杂度的规则包括将函数保持在一定数量的行下（将其分解为较小的函数），或将参数列表保持在一定数量的参数之下（也许应将它们捆绑到一个对象中并传递给对象）。

如果您的团队中的特定开发人员编写的代码很难理解/调试，因为其中包含很多带有单字母变量名称的长代码，这就是采用某些标准的好理由，而不是可以用一个脚本。可以很好地指出（标准地）标准可以改进。

您的经理可能不会将其视为问题的另一个原因是，您实际上并不经常阅读彼此的代码。当每个人都有自己的代码区域并且不对代码区域进行过多尝试时，就会发生这种情况。在有人离开组织之前，这种方法非常有效，这可能由于各种好或坏的原因而发生。帮助提高可读性的标准将使新开发人员更容易接管代码的维护。

合并时发生冲突，因为有人使用其IDE自动格式化，并且他们使用与我不同的缩进字符

听起来这是您的问题，不是格式化，而是重新格式化。对于SCM来说，这是一个巨大的问题，建议很简单：不要这样做。因此，下次有人将所有空格重新设置为制表符格式或将大括号重构为其首选样式时，您需要将其拍下来。让他们进行合并；站在他们面前，不赞成他们的无意识造成的时间浪费。

另一种方法是放入一个预先提交的格式化程序，该格式程序总是在签入之前将所有代码重新格式化为标准样式。如果您有自然要重新格式化的开发人员团队，那么这是一个不错的选择-SCM始终会看到相同的格式，因此增量很小，可以很好地合并。

当有人建议我在哪里工作的新编码标准时，我们会投票赞成。如果获得多数票，则被接受，否则被拒绝。如果不这样做，您将无法获得标准的支持，即使有文档记录，也不会使用它们。

对于您的特定问题，最好的选择可能是从Joel的建议开始，并以身作则。聚集1或2位关心此事的程序员，达成协议，您将有一定的力量强加于那些懒惰的程序员。

现在，对于一般性问题，我发现最好简单地进行调制。每个人都有一个不同的文件，即使您必须维护文件的编码标准，也要保证其编码标准不变，即使该文件的编码标准彼此不同。需要写在同一文件中吗？制作一个子集文件并包含它。

不要尝试这个！

以反例为例。尝试使您的代码格式尽可能地可怕，并检查其他人漂亮代码的可怕格式更改。当发生（不可避免的）反应时，请说您正在做的事很好，因为没有编码标准。

如果您没有被同事私刑（!!），您可能最终会获得编码标准。

显然，这是一种高风险策略... :-)