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.
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: