研究具有标准编码风格的优势
Stackoverflow 上有几个问题，关于是否有任何关于什么是最佳编码约定/风格的研究。这不是这个问题的目的。这个问题是关于是否有任何研究来研究拥有组织范围的编码约定和风格是否有任何优势、生产力提升或其他积极的副作用。
我对此有自己的看法，基本上是，制定这样的标准有巨大的好处。老实说，我不在乎我需要使用什么样式，只要它在我可能需要使用的所有代码中保持一致即可。
我只是想知道是否有任何研究支持或反驳我的观点。
There are a couple of questions on Stackoverflow on whether there is any research or studies into what is the best coding convention/style. That's not what this question is about. This question is about whether there are any studies that research whether there are any advantages, productivity gains or other positive side effects to having an organization-wide coding convention and style.
I have my own opinions on this, which is basically that there is huge benefits to having such standards in place. Honestly, I couldn't care less what style I am required to use as long as it is consistent in all the code I might have to work with.
I just want to know if there are any studies that back my opinions or contradict them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有几项研究表明，严格遵守一致的视觉风格可以帮助经验丰富的程序员在记忆中保留更多的本地问题，而不必记住问题的各个元素。
一致的编码风格有助于组块
这与人类记忆的工作方式有关。这称为分块。例如，一个经过充分研究的现象是，国际象棋大师比不熟悉棋局的人更容易记住棋局。但这只是当这些棋子出现在正常游戏中可能出现的“自然位置”时。如果将棋子放置在随机位置，那么在记住棋盘位置方面，国际象棋大师并不比非国际象棋棋手更好。
同样的概念也适用于程序员。当编码风格一致时，编码结构对程序员来说显得“自然”，并且代码的较大部分更容易理解。我们的短期记忆的容量约为“七加减二”块，因此，那些熟悉的块越大，我们的大脑可以主动在记忆中保存的原始数据就越多（乔治·米勒）。
当面对随机格式的代码时，程序员必须花费额外的精力来手动解析出他们正在处理的问题的各个部分。这就剥夺了将问题的较大部分保存在内存中以进行处理的能力。这也意味着程序员需要更长的时间才能有效地解决手头的问题。
流动时间
您是否曾经发现，当您继续解决某个问题时，它看起来非常清晰，但当您稍后再回到该问题时，您似乎“失去了信息”？即打破你的流动时间？ Flow time 在 Peopleware 中有详细记录（所有程序员必读）。流动时间是指程序员完成大部分工作的时间，并且只有当您长时间不间断地处理问题时才能实现。这是因为程序员需要一定的时间才能将足够的问题吸收到认知记忆中才能有效地解决问题。格式良好的代码有助于我们的视觉图像处理，这意味着程序员可以更快地达到流程时间。
我曾在多家软件公司编写过编码标准。不幸的是，许多程序员认为编码标准只是对他们的工作方式进行不必要的控制的一种手段；创造性审查的一种形式。说实话，实际标准是什么并不重要。其价值在于让团队中的每个人保持一致，即使这意味着在按我的方式还是按你的方式之间做出经常武断的决定。
以下是我上面提到的一些参考：
There have been several studies showing that a strict adherence to a consistent visual style helps experienced programmers keep more of the local problem in memory without having to memorize the individual elements of the problem.
Consistent Coding Style Aids Chunking
It has to do with how the human memory works. It is called chunking. For example, it is a well-studied phenomenon that chess masters are much better at memorizing chess positions than people who are not familiar with the game. But that is only if the pieces occur in "natural positions" that can occur in a normal game. If you place the chess pieces in random positions, chess masters are no better off than non-chess players at memorizing board positions.
The same concept applies to programmers. When coding styles are consistent, the coding constructs appear "natural" to the programmer and larger portions of the code are easier to assimilate. Our short term memory has a capacity of about "seven plus-or-minus two" chunks so, the larger those familiar chunks are, the more raw data our mind can actively hold in memory (George Miller).
When faced with randomly-formatted code, programmers have to expend addition mental energy to manually parse out the individual pieces of the problem they are working on. That takes away from the ability to hold larger pieces of the problem in memory to work on it. It also means that it takes longer to reach a point where the programmer is productively solving the problem at hand.
Flow Time
Have you ever found that a problem seems so clear while you continue to work on it but then you seem to "lose the information" when you come back to the problem later; i.e. break your flow time? Flow time is well-documented in Peopleware (a must read for all programmers). Flow time is when programmers get a large majority of work done and is only achieved when you are working on a problem for an extended, uninterupted period of time. That is because it takes a certain period of time for a programmer to assimilate enough of the problem into cognitive memory to effectively work on the problem. Well-formatted code helps our visual image processing which means programmers reach flow time much faster.
I have authored coding standards at several software companies. It is unfortunate how many programmers feel that coding standards are just a means of asserting unneeded control over how they do things; a form of creative censorship. Truth be told, it rarely matters what the actual standards are. The value is in getting everyone on a team to be consistent, even if it means making an often-arbitrary decision between doing it my way or doing it your way.
Here are a few reference I mentioned above:
编程知识的实证研究。索洛韦和埃利希。
Empirical Studies of Programming Knowledge. Soloway and Ehrlich.
我对这个问题最深入的了解是：
C++ 编码标准：101 条规则、指南、和最佳实践（Sutter、Alexandrescu）
即使您不使用 C++，也值得一读。
The place I gained the most insight on the issue:
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (Sutter, Alexandrescu)
It's worth reading even if you aren't working in C++.