最近我发现我们公司有一套编码准则（藏在一个文件管理系统中，没有人能找到它）。它似乎是相当合理的，避免了关于'{''的放置以及是否使用硬制表符等通常的争论。然而，它建议“行不应包含多个空格”。这意味着不要做这样的事情：
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 },
// ...
}
这样做的理由是更改一行通常需要编辑每一行。这使得更改变得更加费力，并且更难理解差异。
我犹豫不决。一方面，这样排列可以使重复的代码更易于阅读。另一方面，它确实使差异更难以阅读。
你对此有什么看法？
2008年：由于我每天都要监督源代码的合并... 我建议不要使用它。
它看起来很好，但如果你经常进行合并，那么“更易读”的好处很快就远小于合并该代码所需的工作量。
由于这种格式不能轻松自动化，第一个不遵循它的开发人员将触发复杂的合并。
不要忘记，在源代码合并中，无法要求diff工具忽略空格：
否则，“”和“ ”在差异期间看起来相同，这意味着不需要合并...编译器（以及在字符串双引号之间添加空格的程序员）不会同意！
大多数代码合并工具应该能够处理忽略空格和对齐等号是现在大多数IDE的自动格式选项。
我犹豫了。一方面，像这样排列可以使重复的代码更易于阅读。另一方面，它确实使差异更难阅读。
既然让代码易于理解比让变更易于理解更重要，那么你就不应该犹豫。
在我看来，对齐相似行确实大大提高了可读性。此外，它允许在支持垂直选择的编辑器中更轻松地剪切和粘贴。
我从不这样做，而且我总是建议别这么做。我不在乎diffs（差异）更难阅读，我关心的是第一次进行此操作需要花费时间，并且每当行需要对齐时都需要额外的时间。编辑具有这种格式样式的代码非常令人恼火，因为它经常变成一个巨大的时间陷阱，我最终花费的时间比实际做出的更改还要多。
我还质疑这种格式的可读性。这种格式样式会在文件中创建列。但是，我们不会以列样式从上到下“阅读”，我们是从左到右阅读的。这些列分散了标准的阅读方式，将目光拉向下方。如果它们没有完全对齐，这些列也会变得非常丑陋。这适用于不必要的空格，也适用于具有不同间距但相继出现在文件中的多个（可能不相关的）列组。
顺便说一下，我觉得你的编码标准不指定缩进或括号放置方式真的很奇怪。混合使用不同的缩进样式和括号放置方式将远远损害可读性，而不是使用（或不使用）列样式格式。
我从不这样做。正如你所说，有时需要修改每一行以调整间距。在某些情况下（比如上面的条件语句），如果你放弃空格并将块与条件语句分开放置在不同行上，则代码可以更容易阅读和维护。
此外，如果你的编辑器具有良好的语法高亮功能，这种间距实际上并不是必需的。
关于此问题，Steve McConnell 的经典著作——代码大全中有相关讨论。如果你还没有这本书，建议购买一本。在第一版书中（也是我手头的版本），该讨论出现在第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 .：好吧，你仍然需要更改每一行，但这很快而简单。
我遵循两个准则：
尽可能使用制表符而不是空格，以最小化重新格式化的需要。
如果你担心对修订控制的影响，请先进行功能性更改，然后检查它们，再进行纯粹的格式更改。
如果在"纯粹的"更改中引入了错误，则可以公开斥责。 :-)
2020-04-19 更新：十二年后，事情变化多端！如果我今天回答这个问题，可能会说："请让您的编辑器为您格式化代码和/或告诉您的差异工具在进行纯粹更改时忽略空格。
今天，当我审查代码的可读性并认为通过不同的格式来提高其清晰度时，我总是用"...除非编辑器自动执行此操作。不要与您的工具作斗争。他们总是赢得胜利。"