如果同事正在编辑代码只是为了改变外观怎么办？

如果同事正在编辑您的代码，该怎么办？

没有增加功能或修复错误的目的，只是为了改变外观...

和他们谈谈。以“他们没有这样做来惹恼我，或者因为他们患有某种形式的强迫症；他们试图使我的代码更好”的态度进入对话。

因为你可能错了。那可能是一个微妙的错误修复，而您只是没有发现它。

或者，可能是因为您不知道您正在违反的编码标准，而他们只是在纠正它。

或者，可能是他们试图惹恼您，或者他们患有某种形式的强迫症。如果是这样，请让他们停下来，如果还是无效，请与您的老板联系。

但是除非你问，否则你永远不会知道。

我不太喜欢我的代码如何困扰我。:)我尝试从变化中学习。我的同事是否调整了变量名？写一个更有效的循环？使代码更具可读性？

如果我看不到更改如何改善了已有的内容，我通常会问进行更改的同事背后的动机是什么。优势可能对我而言并不明显。如果我是对的，但他们是错的，那么也许我可以解释为什么我以自己的方式写作。

如果其他所有方法均失败，请还原签入。;）

编辑：但是，如果进行外观更改的愿望引入了错误，则所有赌注都关闭。

无论如何，IMO和您以及您的团队都应该使用编码标准。如果是这样，那么问题就变成“您的原始代码是否符合标准？” 如果为“是”，那么您的同事应该不修改您的代码，除非对其进行功能上的更改。如果为“否”，那么恐怕您的同事有权利整理您的代码。作为项目负责人，我发现自己一直在这样做。

如果您不使用编码标准，那么关于什么构成“良好代码”的争论变得过于主观。因此，为什么要使用编码标准:)

作为一个的人，主要的原因，我这样做是可读性（谁偶尔格式化别人的代码的人）。有些人的缩进或混合制表符和空格都非常草率。

我习惯更改的主要内容是减少长行，以便无需横向滚动即可阅读整个内容。我会将复杂的语句分解为单独的语句或重新格式化方法调用/声明，以在每行中都不能很好地容纳一个参数的情况下在每行列出一个参数。我还将编辑评论，以修复英文错误或使内容更清楚。

是的，我可以不理会它，但是我宁愿减少阅读代码所需的精力。

你应该怎么做？首先，请考虑这个人可能正在使您的代码更好。另外，您应该确保团队中就如何格式化代码达成共识。如果每个人都有不同的习惯，则会减慢每个人的成长速度。如果他们没有使您的代码变得更好，并且违背了原则，那么您就需要面对它们。如果那不起作用，那么您可能需要让其他人参与。

问他们为什么这样做？一个有效的解释可能会减轻您的挫败感，但您应该让他们知道这有多困扰您。谁知道，也许他们认为他们在帮您一个忙，一旦得知您的冒犯就会停止。或者您可能正在与真正患有医疗状况的人打交道。

他/他被允许吗？所做的更改会改进代码吗？如果是这样，请吞下你的骄傲。如果您认为代码质量变差，请与同事联系，并询问他们为什么他们觉得需要更改您的代码而没有明显的好处。如果这样做是出于恶意，或者是因为该人错误地认为他们比您强，而您无法与他们一起解决，请与您的老板接洽。

像Visual Studio这样的IDE都有一个名为的选项Format Document，该选项将根据用户在IDE中设置的规则来格式化代码。可能是您的同事正在使用此功能（自动运行或不知情，或通过故意的应用程序）。也许他们的IDE使用空格而不是制表符，反之亦然，并且这些空格在不知不觉中被自动应用了吗？但是您需要与他们交谈以找出答案。

顺便说一句，如果很明显我没有遵循某种格式化方案（即到处都是），我经常会重新格式化同事的代码。这是一种使他们引起注意的微妙方法。（但是，如果它整洁，我不会重新格式化它，但我不喜欢）。

如果他要对其进行更改，使其符合您团队的编码标准，则下次应遵循该标准。

如果他更改了代码，使其不再符合您团队的编码标准，请告知他他做错了什么，然后请他将其更改回来。

...您的团队确实有一套供所有人使用的代码格式标准，对吗？

我有时会重新排序凌乱的同事编写的代码（或修正注释中的拼写错误）。他们知道我沉迷于代码格式和顺序，因此他们让我做到了，而又不用抱怨太多。有时他们还会给我免费的苏打水或饼干。

当然，这是偶然的工作，因为它打破了SVN中的“怪”功能。

这也是进行某种代码审查的一种非常基本的方法（我通常在我正在处理的模块中阅读我的同事提交的大多数代码）。

代码约定是的答案。您应该在工作。如果您不这样做，请立即开始（一个很好的起点是谷歌风格指南）。当有书面规则（或至少是众所周知的规则）时，对您问题的答案很简单。

我觉得您认为这样做是令人反感的...？例如，我本人会立即修复此代码

int myFunction( ) {

    int i ;
  return  0;

}

成为

int myFunction() {
    int i;
    return 0;
}

所以...我应该因为自己的行为受到惩罚吗？在现实生活中，我实际上有大量的SVN日志读为“格式”。;-)

使用样式检查工具

开始使用StyleCop或类似样式并强制执行代码样式规则，并使所有开发人员都有义务使用它。所有代码将毫无例外地看起来一样。并与明智的人一起讨论最适合您组织的规则。即使默认规则已经非常类似于.net框架代码本身。

这是最简单的方法。我发现自己在我以前的一位雇主中正在纠正别人的代码，因为另一个人正在编写的代码中带有过多的空行并且没有任何缩进规则。普通开发人员实际上无法读取代码。如果StyleCop能够早日存在，那么它将使我们许多人真正感到高兴。

这是我在互联网上看到的关于重构的想法，也许可以解释为什么有人会触摸您的代码以使其更好：

为什么？

重构的主要原因有两个：

1. 在构建代码/设计之前要对其进行改进：初次尝试时很难拿出好的代码。实施任何初始设计的第一次尝试都会向我们表明，我们误解或忘记了一些逻辑。

2. 适应需求的变化。软件开发中发生了变化；响应变化最好具有良好的代码库。对于这两种情况，我们都有两个选择，即代码路径或重构代码。修补代码将导致我们无法维护的代码，并增加我们的技术负担，因此重构总是更好的选择。

什么时候？

1. 越快越好越容易。

2. 通过最近重构的代码进行重构的速度更快，风险更低，而不必等待重构几乎完成的代码。

什么？

1. 所有的代码和所有的设计都是重构的候选者。

2. 不重构某些东西的例外情况可能是质量低的工作代码，但是由于接近最后期限，我们宁愿保留技术债务而不愿冒险进行规划。

如果这对双方都有利，那么您只需要让他尽自己最大的努力，并节省您将来的时间！

干杯