最近，我发现我们公司有一套编码准则（隐藏在文档管理系统中，没人能找到它）。通常，这似乎非常明智，并且避免了通常的宗教战争，即在何处放置“ {”以及是否使用硬标签。但是，它确实建议“行不应包含嵌入的多个空格”。这意味着不要做这种事情：
foo = 1;
foobar = 2;
bar = 3;
或此：
if ( test_one ) return 1;
else if ( longer_test ) return 2;
else if ( shorter ) return 3;
else return 4;
或此：
thing foo_table[] =
{
{ "aaaaa", 0 },
{ "aa", 1 },
// ...
}
这样做的理由是，更改一行通常需要编辑每一行。这使得更改变得更加努力，并且很难理解差异。
我很伤心。一方面，这样排列可以使重复的代码更容易阅读。另一方面，它确实使差异难以阅读。
您对此有何看法？
由于我监督源代码的日常合并，所以我只能建议反对它。
这很漂亮，但是如果您定期合并，“易读”的好处将远远少于合并该代码所涉及的工作。
由于无法轻松地自动格式化，因此第一个不遵循该格式的开发人员将触发非平凡的合并。
不要忘记在源代码合并中，不能要求diff工具忽略空格：否则，“”和“”在差异期间将看起来相同，这意味着不需要合并...编译器（以及在字符串双引号之间添加空格的编码器）将不同意！
我很伤心。一方面，排队这样可以制作重复的代码更容易阅读。在另一手，这确实使差异变得更难阅读。
好吧，因为使代码易于理解比使差异易于理解更为重要，所以您不应该被撕裂。
恕我直言，将相似的行排成一行确实可以大大提高可读性。此外，它允许使用允许垂直选择的编辑器更轻松地进行剪切粘贴。
我从不这样做，我总是建议不要这样做。我不在乎差异很难阅读。我确实在意，这样做首先需要花费时间，并且每当必须重新对齐行时都需要花费额外的时间。编辑具有这种格式样式的代码非常令人讨厌，因为它通常会占用大量时间，而且我最终花费了更多的时间格式化，而不是进行真正的更改。
我也对可读性优点提出了质疑。这种格式样式会在文件中创建列。但是，我们不会在列样式中从上到下read。我们从左到右阅读。列分散了标准阅读样式的注意力，并向下拉眼睛。如果所有列都不完全对齐，它们也会变得非常难看。这适用于无关的空格，但也适用于多个（可能是不相关的）列组，它们的间距不同，但在文件中一个接一个地排列。
顺便说一句，我发现您的编码标准没有指定制表符或大括号的位置确实很奇怪。与使用（或不使用）列样式格式混合使用，将不同的制表符样式和花括号位置混合使用会大大损害可读性。
我从不这样做。如您所说，有时需要修改每行以调整间距。在某些情况下（例如上面的条件），如果您消除了间距并将这些块与条件分开放在单独的行中，那么它将很容易阅读并且易于维护。
此外，如果您在编辑器中突出显示了不错的语法，则这种间距实际上不是必需的。
在史蒂夫·麦康奈尔（Steve McConnell）经常使用的Code Complete中对此进行了一些讨论。如果您没有这本开创性书籍的副本，请帮自己一个忙，买一本。无论如何，讨论是在第一版的426和427页上进行的，这是我所掌握的版本。
编辑：
McConnell建议在一组赋值语句中对齐等号以表明它们是相关的。他还告诫不要在一组作业中对齐所有等号，因为它可以在视觉上暗示没有关系的关系。例如，这将是适当的：
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
虽然这不会
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
我相信差异是显而易见的。也有一些关于对齐连续线的讨论。
我个人更喜欢更高的代码可读性，但代价是稍微难于读取差异。在我看来，从长远来看，值得改善代码的可维护性-特别是随着开发人员的到来-值得权衡。
[拥有出色的编辑，他们的观点是不正确的。 ：）
（请参见vim的“可视块”模式。]
P.S .：好的，您仍然需要更改每一行，但是它既快速又简单。
我尝试遵循两个准则：
尽可能使用制表符代替空格，以尽量减少重新格式化的需要。
如果您担心对版本控制的影响，请先进行您的[[功能更改，将其检入，然后进行仅修饰性的更改。
] >>