与编码风格不一致的同事打交道？

当您与倾向于编写风格上很差的代码的人一起工作时，您会怎么办？我正在谈论的代码在技术上通常是正确的，结构合理的，甚至在算法上可能是优雅的，但看起来却很丑陋。我们有：

• 不同命名约定和标题的混合（underscore_style和camelCase和UpperCamel以及CAPS全部或多或少地随机应用于同一函数中的不同变量）
• 奇异且不一致的间距，例如 Functioncall (arg1 ,arg2,arg3 );
• 注释和变量名中很多拼写错误的单词

我们有一个很好的代码审查系统，可以正常工作，因此我们可以仔细研究并修复最糟糕的问题。但是，发送包含50行“在此处添加空格。正确拼写'itarator'。更改此大写字母等”的代码审核确实很琐碎。

您如何鼓励这个人更加小心并与这些细节保持一致？

同意编码约定

即使这是一个寻呼机。我建议整个团队坐下来，大家都同意整个团队可以使用的基本工作编码约定。

我认为您只需要继续做自己正在做的事情即可。有一套清晰的编码准则，并在代码审查期间执行它们。如果开发人员每次尝试签入某项内容时得到50或100行“在此处添加空格”和“正确拼写“迭代器””，而实际上在所有这些问题都得到解决之前，他实际上不被允许签入，为了避免麻烦，必须开始编写更简洁的代码。

我认为，如果您自己修复这些问题（如NimChimpsky建议的那样），那么您将永远在清理这个人。

我打电话给BS，每个人都说变量名的拼写错误和格式无关紧要。显然，他们只阅读自己的代码。并注意那里的单词-阅读。想象一下，读一本书时会遇到很多拼写错误，杂乱无章的格式设置，行距不一致以及许多源代码中普遍存在的其他惰性现象。这将是乏味的。

对于您的语法必须100％正确工作的专业而言，任何真正的开发人员都没有没有干净，一致的代码风格的借口。其他就是草率和懒惰。我总是质疑草率格式化的代码在实现中的正确性。

我们有一个很好的代码审查系统，可以正常工作，因此我们可以仔细研究并修复最糟糕的问题。但是，发送包含50行“在此处添加空格。正确拼写'itarator'。更改此大写字母等”的代码审核确实很琐碎。

我会自己更改它，然后在代码中添加一个礼貌的注释。

假设问题已经存在，如：

我们有一个好的代码审查系统

因此，我的建议是不得已而为之，我认为自己进行更改和发表评论一样快，就像发送电子邮件或其他内容一样。

我认为诸如类和变量的命名之类的约定很重要，并且优雅，高效的代码也应遵循这些约定，但是冒着我的答案被多次否决的风险，我不得不说，一般来说，“漂亮的代码”范式在恕我直言，很多推是非常高估的。

首先，编写它的开发人员必须首先维护它，如果他被总线撞到了而另一个程序员无法弄清楚它是如何工作的，因为代码不是“漂亮”的，我会说反正其他开发者也不是很好。而且那里有很多自动格式化程序/美化程序，因此任何人都可以在必要时使用它们来美化代码，而不必浪费时间在“流程中” /“在区域中”。

请注意，我在这里不提倡意大利面条/牛仔风格的编码，实际上，我已经看到了一些格式很好的意大利面条代码（功能主体跨越4-5个屏幕，全局变量分散在不同的源代码文件中，通常名称不正确等）。

我的一位同事以使我的皮肤爬行的方式编写html。想象一下我的html很好，结构上有两个空格缩进，被添加到我的末尾的标签砍成碎片，这些标签在同一行或下一行结束，就像一些醉酒的人，他需要用胳膊将你抱住以保持站立。新行很少缩进，但如果是新行，我敢肯定，在银河系的某些部分会出现一些高度混乱的黑洞，以不合理的温度值吐出，以某种方式使其数字反映出这种缩进中使用的空格或制表符的数量由这个女人。如果幸运的话，我会看到一个以“ </input>” 关闭的输入标签。您可以理解的噩梦。

似乎也没有人理解这一点，看到对他们来说，对于大多数较高级别的用户来说，有组织的代码或无组织的代码的感觉就像我们将瑞士奶酪或美国奶酪放在三明治上的区别一样，也就是说，他们实际上不太在乎。我开始让它滑动，因为我承受着另一个项目的压力，而且我认为她开始意识到在想要改进之前很难理解这样的代码。我的建议是证明为什么比起简单地告诉他们这样做，更喜欢对代码进行样式设置。

我正在谈论的代码通常在技术上是正确的，结构合理的，甚至在算法上也可能是优雅的...

为您获得所有这些而高兴。大多数程序员可能会在清单上给您第一件事。我认为变量命名和间距是最不重要的事情。

听起来您需要设置并同意样式约定。如果不这样做，您将拥有包含3个空格缩进的库，其他包含4个缩进的库，其中一些使用Camel Case，另一些使用underscore_case。

是要根据个人喜好进行更改，还是要遵循实际标准？如果您没有实际的标准，则不要这样做。首先设定一个标准。然后，您可以获得可以设置为将代码重构为标准设置（至少在某些情况下）的软件。

如果您有标准，请在代码审查中开始执行。如果您没有在代码审查中强制执行标准，那没有任何意义。这将意味着需要进行大量额外的维护工作，因为人们在接触原始代码时，必须修复最初不符合标准的旧代码。

即使没有标准，也要坚持解决变量名中的拼写错误（我不会特别担心注释），因为它们会使所有接触代码的人永远疯狂。

需要确定编码标准，以便每个人都知道它们是什么，然后才需要执行它们。不遵守规则会有后果。

以下是一些应该提供激励的东西：

1. 代码审查将很繁琐，而且比必要的时间还要长。
2. 代码将被更频繁地拒绝。
3. 时间表将无法实现。

如果这个人不必因为没有人执行您的规则而担心这个问题，或者他们不在乎它们是否无效（也没有人对此做任何事情），那么您对此无能为力。

我很想建议进行私人聊天，看看你们俩是否都能找到根本原因：

1. 同事是否赶时间，并且因为某人昨天想要该代码，所以该人正试图使某些东西尽快工作？这可能是一个机会，可以告知此人更多地关注质量而不是工作速度。如果这不会适得其反，那么“花点时间”这样的口号可能会很有用。

2. 这个人如何看待他们的工作？如果有一种自豪感，那么您可能有一个角度可以用来改善自己。如果仅仅是支付账单的工作，则找零可能会困难得多。他们是否知道自己做得并不出色，但情况如此接近？

3. 此人是否不同意公约并试图编写代码以示抗议？如果是这样，那么您可能会有一个大问题，但这值得一查到底是这样还是该人只是懒惰？什么样的动机在这里可能有用，例如，您可以诉诸于贪婪，自尊心或其他恶习来使人得到改善。这是偷偷摸摸的，但如果尝试通过好人路线却无济于事，可能会有效。

4. 如何赢得朋友和影响力人们在说服力方面可能有一些建议，例如赞美改进并给予人以良好的声誉以维护。

至于为什么必须私下完成此操作，有以下几个原因：

1. 蒙羞，批评或其他不愉快的可能性很大，最好是躲在门后，而不是在露天场所，人们可能会觉得自己的性格被暗杀。

2. 您想鼓励其他人开放一点。这里的挑战是有些人受到如此谨慎的保护，可能需要很长时间才能使他们倒塌。

3. 如果可能的话，我建议您在远离办公室的地方尝试这样做。外出享用午餐，散步或做点什么，以使周围的环境发生足够的改变，使人可能会感到更舒适。这可能是一个挑战，需要认识这个人，但是这里的想法是，在办公室里有些人会戴上防毒面具，这在这里可能没有帮助。

4. 准备使对话变​​得更加热烈或丑陋，但这很可能是一个好兆头，如果您可以让其他人参与其中并进行良好的对话。有些人喜欢将事情公开进行，而另一些人则更喜欢用更微妙的方式来完成事情。关键是要确保您正在倾听对方的声音，以充分体谅并尝试理解对方。

我们有一个JUnit测试，用于查找格式问题。它作为构建的一部分运行。我通过省略if，while或for和左括号之间的空格来不断获取信息。但是，我们的代码是一致的格式。

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

像unscrutify这样的代码美化将能够解决您的一些问题。如果您准备为此付费，那么可以使用高级软件，例如Parasoft，将规则嵌入源代码中。Parasoft强制必须以统一的样式编写代码。您也可以嵌入自己的规则。使用此类工具时，开发人员被迫使用统一样式。过了一会儿，他们会习惯的。

如果使用Eclipse，则为Java编辑器启用“保存操作”，并告诉所有人使用它。这可以解决每次保存时的格式问题，但不能解决大写错误。可能会很有帮助！

遵循样式约定有多难？我了解拼写错误，但其余部分则表明思维和编码草率。告诉人们，在生产代码方面，他们需要更加一致，因为他们不是唯一会关注代码的人。以不一致的风格编写生产代码只是粗鲁，自私和考虑不周。

大声笑。您绝对会讨厌我的代码。我无法拼命挽救生命，也不在乎。

但是我知道有些人确实关心那些事情。

我建议您解雇编写丑陋代码的人，如果他们没有改变，然后找一个能使事情变得非常漂亮的人，并希望他们能写出能够

在技​​术上通常是正确的，结构合理，甚至在算法上也可能很优雅

如果他们不能这样做，那么至少您可以向客户展示损坏的漂亮代码，然后将其出售！

不过实话说。首先关注实际重要的事情。如果您在“它伤害了我的敏锐情感”之外找不到一个很好的可靠理由，那么现在就忽略它。如果真的很重要，请与该人坐下并说服他们。诸如标准之类的东西很容易区分类级别，方法级别，共享常量变量之间的区别。如果有问题的编码人员完全关心他/她的职业，他们将理解并尝试做正确的事情。

当处理外包资源时，我的解决方案没有提供有关格式的＆％$＃信息（或者很容易避免的错误），我的解决方案是让构建服务器强制执行此操作。我创建了一个CI服务器作业，该作业每天晚上运行，检出代码，运行Jalopy和findbugs，然后将代码检入。一旦其他团队得知不使用标准代码约定会使他们的工作更困难，他们便开始使用IDE保持标准格式。