2008: Since I supervise daily merges of source code,... I can only recommend against it.
It is pretty, but if you do merges on a regular basis, the benefit of 'easier to read' is quickly far less than the effort involved in merging that code.
Since that format can not be automated in a easy way, the first developer who does not follow it will trigger non-trivial merges.
Do not forget that in source code merge, one can not ask the diff tool to ignore spaces : Otherwise, "" and " " will look the same during the diff, meaning no merge necessary... the compiler (and the coder who added the space between the String double quotes) would not agree with that!
I never do this, and I always recommend against it. I don't care about diffs being harder to read. I do care that it takes time to do this in the first place, and it takes additional time whenever the lines have to be realigned. Editing code that has this format style is infuriating, because it often turns into a huge time sink, and I end up spending more time formatting than making real changes.
I also dispute the readability benefit. This formatting style creates columns in the file. However, we do not read in column style, top to bottom. We read left to right. The columns distract from the standard reading style, and pull the eyes downward. The columns also become extremely ugly if they aren't all perfectly aligned. This applies to extraneous whitespace, but also to multiple (possibly unrelated) column groups which have different spacing, but fall one after the other in the file.
By the way, I find it really bizarre that your coding standard doesn't specify tabbing or brace placement. Mixing different tabbing styles and brace placements will damage readability far more than using (or not using) column-style formatting.
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)
. . .
我相信差异是显而易见的。 还有一些关于对齐连续线的讨论。
There is some discussion of this in the ever-useful Code Complete by Steve McConnell. If you don't own a copy of this seminal book, do yourself a favor and buy one. Anyway, the discussion is on pages 426 and 427 in the first edition which is the edition I've got an hand.
Edit:
McConnell suggests aligning the equal signs in a group of assignment statements to indicate that they're related. He also cautions against aligning all equal signs in a group of assignments because it can visually imply relationship where there is none. For example, this would be appropriate:
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
While this would not
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
I trust that the difference is apparent. There is also some discussion of aligning continuation lines.
I never do this. As you said, it sometimes requires modifying every line to adjust spacing. In some cases (like your conditionals above) it would be perfectly readable and much easier to maintain if you did away with the spacing and put the blocks on separate lines from the conditionals.
Also, if you have decent syntax highlighting in your editor, this kind of spacing shouldn't really be necessary.
Personally I prefer the greater code readability at the expense of slightly harder-to-read diffs. It seems to me that in the long run an improvement to code maintainability -- especially as developers come and go -- is worth the tradeoff.
Use tabs instead of spaces whenever possible to minimize the need to reformat.
If you're concerned about the effect on revision control, make your functional changes first, check them in, then make only cosmetic changes.
Public flogging is permissible if bugs are introduced in the "cosmetic" change. :-)
2020-04-19 Update: My, how things change in a dozen years! If I were to answer this question today, it would probably be something like, "Ask your editor to format your code for you and/or tell your diff tool to ignore whitespace when you're making cosmetic changes.
Today, when I review code for readability and think the clarity would be improved by formatting it differently, I always end the suggestion with, "...unless the editor does it this way automatically. Don't fight your tools. They always win."
My stance is that this is an editor problem: While we use fancy tools to look at web pages and when writing texts in a word processor, our code editors are still stuck in the ASCII ages. They are as dumb as we can make them and then, we try to overcome the limitations of the editor by writing fancy code formatters.
The root cause is that your compiler can't ignore formatting statements in the code which say "hey, this is a table" and that IDEs can't create a visually pleasing representation of the source code on the fly (i.e. without actually changing one byte of the code).
One solution would be to use tabs but our editors can't automatically align tabs in consecutive rows (which would make so many thing so much more easy). And to add injury to insult, if you mess with the tab width (basically anything != 8), you can read your source code but no code from anyone else, say, the example code which comes with the libraries you use. And lastly, our diff tools have no option "ignore whitespace except when it counts" and the compilers can't produce diffs, either.
Eclipse can at least format assignments in a tabular manner which will make big sets of global constants much more readable. But that's just a drop of water in the desert.
We had a similar issue with diffs at multiple contracts... We found that tabs worked best for everyone. Set your editor to maintain tabs and every developer can choose his own tab length as well.
Example: I like 2 space tabs to code is very compact on the left, but the default is 4, so although it looks very different as far as indents, etc. go on our various screens, the diffs are identical and doesn't cause issues with source control.
If you're planning to use an automated code standard validation (i.e. CheckStyle, ReShaper or anything like that) those extra spaces will make it quite difficult to write and enforce the rules
发布评论
评论（14）
2008 年：由于我负责监督源代码的日常合并，...我只能建议不要这样做。
它很漂亮，但是如果您定期进行合并，那么“更易于阅读”的好处很快就远远小于合并代码所涉及的工作量。
由于该格式无法以简单的方式实现自动化，因此第一个不遵循该格式的开发人员将触发重要的合并。
不要忘记在源代码合并中，不能要求 diff 工具忽略空格：
否则，“”和“”在比较过程中看起来是一样的，这意味着不需要合并......编译器（以及在字符串双引号之间添加空格的编码器）不会同意这一点！
2020 年：正如评论中所述马可
我仍然更喜欢带有自己的格式选项的语言，例如 Go 及其
gofmt命令。甚至 Rust 也有它的
rustfmt现在。2008: Since I supervise daily merges of source code,... I can only recommend against it.
It is pretty, but if you do merges on a regular basis, the benefit of 'easier to read' is quickly far less than the effort involved in merging that code.
Since that format can not be automated in a easy way, the first developer who does not follow it will trigger non-trivial merges.
Do not forget that in source code merge, one can not ask the diff tool to ignore spaces :
Otherwise, "" and " " will look the same during the diff, meaning no merge necessary... the compiler (and the coder who added the space between the String double quotes) would not agree with that!
2020: as noted in the comments by Marco
I still prefer languages which come with their own formatting options, like Go and its
gofmtcommand.Even Rust has its
rustfmtnow.好吧，由于使代码易于理解比使差异易于理解更重要，因此您不应该感到困惑。
恕我直言，排列相似的行确实大大提高了可读性。 此外，它允许使用允许垂直选择的编辑器更轻松地进行剪切粘贴。
Well, since making code understandable is more important than making diffs understandable, you should not be torn.
IMHO lining up similar lines does greatly improve readability. Moreover, it allows easier cut-n-pasting with editors that permit vertical selection.
我从来不这样做，而且我总是建议不要这样做。 我不在乎差异是否更难阅读。 我确实关心首先需要时间来完成此操作，并且每当需要重新对齐线路时都需要额外的时间。 编辑具有这种格式样式的代码是令人恼火的，因为它通常会耗费大量时间，而且我最终花在格式化上的时间比进行真正更改的时间还要多。
我对可读性的好处也有争议。 此格式设置样式会在文件中创建列。 但是，我们不会以分栏方式从上到下阅读。 我们从左到右阅读。 这些专栏分散了标准阅读风格的注意力，并将视线向下拉。 如果柱子没有完全对齐，它们也会变得极其难看。 这适用于无关的空白，也适用于多个（可能不相关的）列组，这些列组具有不同的间距，但在文件中一个接一个地排列。
顺便说一句，我发现你的编码标准没有指定制表符或大括号的位置，这真的很奇怪。 混合不同的制表符样式和大括号放置对可读性的损害远远大于使用（或不使用）列样式格式。
I never do this, and I always recommend against it. I don't care about diffs being harder to read. I do care that it takes time to do this in the first place, and it takes additional time whenever the lines have to be realigned. Editing code that has this format style is infuriating, because it often turns into a huge time sink, and I end up spending more time formatting than making real changes.
I also dispute the readability benefit. This formatting style creates columns in the file. However, we do not read in column style, top to bottom. We read left to right. The columns distract from the standard reading style, and pull the eyes downward. The columns also become extremely ugly if they aren't all perfectly aligned. This applies to extraneous whitespace, but also to multiple (possibly unrelated) column groups which have different spacing, but fall one after the other in the file.
By the way, I find it really bizarre that your coding standard doesn't specify tabbing or brace placement. Mixing different tabbing styles and brace placements will damage readability far more than using (or not using) column-style formatting.
Steve McConnell 的《Code Complete》中对此进行了一些讨论。 如果您没有这本开创性的书，那就帮自己一个忙，买一本。 无论如何，讨论是在第一版的第 426 和 427 页上，这是我手上的版本。
编辑：
麦康奈尔建议对齐一组赋值语句中的等号以表明它们是相关的。 他还警告不要在一组作业中对齐所有等号，因为这可能会在视觉上暗示不存在任何关系。 例如，这将是适当的：
虽然这不会，但
我相信差异是显而易见的。 还有一些关于对齐连续线的讨论。
There is some discussion of this in the ever-useful Code Complete by Steve McConnell. If you don't own a copy of this seminal book, do yourself a favor and buy one. Anyway, the discussion is on pages 426 and 427 in the first edition which is the edition I've got an hand.
Edit:
McConnell suggests aligning the equal signs in a group of assignment statements to indicate that they're related. He also cautions against aligning all equal signs in a group of assignments because it can visually imply relationship where there is none. For example, this would be appropriate:
While this would not
I trust that the difference is apparent. There is also some discussion of aligning continuation lines.
我从来不这样做。 正如您所说，有时需要修改每一行来调整间距。 在某些情况下（如上面的条件语句），如果您取消间距并将块放在与条件语句不同的行上，那么它会完全可读并且更容易维护。
另外，如果您的编辑器中有不错的语法突出显示，那么这种间距实际上并不是必要的。
I never do this. As you said, it sometimes requires modifying every line to adjust spacing. In some cases (like your conditionals above) it would be perfectly readable and much easier to maintain if you did away with the spacing and put the blocks on separate lines from the conditionals.
Also, if you have decent syntax highlighting in your editor, this kind of spacing shouldn't really be necessary.
对于一个好的编辑来说，他们的观点是不正确的。 :)
（请参阅 vim 的“视觉块”模式。）
PS：好的，您仍然需要更改每一行，但它快速且简单。
With a good editor their point is just not true. :)
(See "visual block" mode for vim.)
P.S.: Ok, you still have to change every line but it's fast and simple.
就我个人而言，我更喜欢更高的代码可读性，但代价是稍微难以阅读的差异。 在我看来，从长远来看，代码可维护性的改进——尤其是当开发人员来来去去时——是值得权衡的。
Personally I prefer the greater code readability at the expense of slightly harder-to-read diffs. It seems to me that in the long run an improvement to code maintainability -- especially as developers come and go -- is worth the tradeoff.
我尝试遵循两个准则：
尽可能使用制表符而不是空格，以最大程度地减少重新格式化的需要。
尽可能
如果您担心对版本控制的影响，请先进行功能更改，将其签入，然后仅进行外观更改。
如果“外观”更改中引入了错误，则公开鞭打是允许的。 :-)
2020-04-19 更新： 天啊，十几年来事情发生了多么大的变化！ 如果我今天回答这个问题，可能会是这样的，“请你的编辑器为你格式化代码和/或告诉你的 diff 工具在你进行外观更改时忽略空格。
今天，当我审查代码时为了可读性并认为通过不同的格式可以提高清晰度，我总是以“......除非编辑器自动这样做”来结束建议。 不要与你的工具作斗争。 他们总是赢。”
I try to follow two guidelines:
Use tabs instead of spaces whenever possible to minimize the need to reformat.
If you're concerned about the effect on revision control, make your functional changes first, check them in, then make only cosmetic changes.
Public flogging is permissible if bugs are introduced in the "cosmetic" change. :-)
2020-04-19 Update: My, how things change in a dozen years! If I were to answer this question today, it would probably be something like, "Ask your editor to format your code for you and/or tell your diff tool to ignore whitespace when you're making cosmetic changes.
Today, when I review code for readability and think the clarity would be improved by formatting it differently, I always end the suggestion with, "...unless the editor does it this way automatically. Don't fight your tools. They always win."
我的立场是，这是一个编辑器问题：虽然我们使用精美的工具查看网页以及在文字处理器中编写文本，但我们的代码编辑器仍然停留在 ASCII 时代。 它们是我们能做到的最愚蠢的，然后，我们尝试通过编写花哨的代码格式化程序来克服编辑器的限制。
根本原因是您的编译器无法忽略代码中的格式化语句，这些语句表示“嘿，这是一个表”，并且 IDE 无法动态创建源代码的视觉上令人愉悦的表示（即没有 实际上改变了代码的一个字节）。
一种解决方案是使用制表符，但我们的编辑器无法自动对齐连续行中的制表符（这将使很多事情变得更加容易）。 雪上加霜的是，如果你弄乱了制表符宽度（基本上是任何东西！= 8），你可以阅读你的源代码，但不能阅读其他人的代码，例如附带的示例代码您使用的库。 最后，我们的 diff 工具没有选项“忽略空白，除非它很重要”，并且编译器也无法生成 diff。
Eclipse 至少可以以表格方式格式化赋值，这将使大量全局常量更具可读性。 但这只是沙漠中的一滴水。
My stance is that this is an editor problem: While we use fancy tools to look at web pages and when writing texts in a word processor, our code editors are still stuck in the ASCII ages. They are as dumb as we can make them and then, we try to overcome the limitations of the editor by writing fancy code formatters.
The root cause is that your compiler can't ignore formatting statements in the code which say "hey, this is a table" and that IDEs can't create a visually pleasing representation of the source code on the fly (i.e. without actually changing one byte of the code).
One solution would be to use tabs but our editors can't automatically align tabs in consecutive rows (which would make so many thing so much more easy). And to add injury to insult, if you mess with the tab width (basically anything != 8), you can read your source code but no code from anyone else, say, the example code which comes with the libraries you use. And lastly, our diff tools have no option "ignore whitespace except when it counts" and the compilers can't produce diffs, either.
Eclipse can at least format assignments in a tabular manner which will make big sets of global constants much more readable. But that's just a drop of water in the desert.
我喜欢第一个和最后一个，但不太喜欢中间的。
I like the first and last, but not the middle so much.
这正是上帝赋予制表符的原因——在行中间添加一个字符不会破坏对齐。
This is PRECISELY the reason the good Lord gave as Tabs -- adding a character in the middle of the line doesn't screw up alignment.
我们在多个合同的差异方面也遇到了类似的问题……我们发现选项卡最适合每个人。 设置编辑器来维护制表符，每个开发人员也可以选择自己的制表符长度。
示例：我喜欢 2 个空格制表符，代码在左侧非常紧凑，但默认值是 4，因此虽然在缩进等方面看起来非常不同，但在我们的各种屏幕上，差异是相同的并且不会导致源代码控制问题。
We had a similar issue with diffs at multiple contracts... We found that tabs worked best for everyone. Set your editor to maintain tabs and every developer can choose his own tab length as well.
Example: I like 2 space tabs to code is very compact on the left, but the default is 4, so although it looks very different as far as indents, etc. go on our various screens, the diffs are identical and doesn't cause issues with source control.
您可以将 diff 工具设置为忽略空格（GNU diff：-w）。
这样，您的差异将跳过这些行并仅显示真正的更改。 非常便利！
You can set your diff tool to ignore whitespace (GNU diff: -w).
This way, your diffs will skip those lines and only show the real changes. Very handy!
如果您计划使用自动代码标准验证（即 CheckStyle、ReShaper 或类似的东西），这些额外的空格将使编写和执行规则变得非常困难
If you're planning to use an automated code standard validation (i.e. CheckStyle, ReShaper or anything like that) those extra spaces will make it quite difficult to write and enforce the rules