I have this theory, but I don’t have a statistically large enough data set  with which to publish anything other than a random musing. My theory is that developers who use a text editor with its “Outlining Mode”  switched on have a tendency to write more “complex” code.
Of course tarring every developer with the same brush is not exactly endearing myself to my readership and so I fully expect there to be many who use this feature with great aplomb and are aware of its apparent shortcomings. However for those who are unsure as to why I’m proposing this theory let me explain what it is that I’ve seen when working with developers who have this feature switched on.
The most obvious thing I’ve noticed is that developers who don’t see all the code on screen at once don’t notice all the duplication. If I’ve spotted a problem in a method then, as a natural by-product of seeing all the code for the class, I’ve also noticed the same pattern appears in a number of other places. In contrast when pairing with someone who can only see the method names, except for the one being currently edited, they do not automatically notice and therefore go looking for any duplication.
Of course the real problem is the duplication itself. I suspect that because I always see all the code I tend to see duplication as it builds up and so will naturally refactor it as soon as the test goes green. When all you see is method names I’m not sure how you are expecting to notice duplication unless you literally cut-and-pasted some other code. At least with code literally cut-and-pasted it looks identical, but when you’ve written code that only appears logically similar to that in another method it can be harder to reason away the duplication and do the necessary refactoring.
In a more general sense what appears to be happening is that, paradoxically, the tool that tries to reduce the noise and clutter whilst editing code has succeeded in creating further complexity by constantly hiding it. If you do not “feel the pain” caused by working with overly complex code you do not feel the need to refactor it, until it becomes a problem, by which point you’ve probably already lost the battle. By having all the code in a source file visible you get to see the big picture so that even if you’re making edits to one method your subconscious can still go to work on the surrounding code and nudge you when it thinks something smelly is appearing.
Debugging is another opportunity where you get to take a walk through code you’ve perhaps not worked on yourself. In effect you have the opportunity to review that code as you’re debugging it, not formally, but you can certainly makes notes and raises any issues later (See “In The Toolbox - Pen & Paper”).
The use of regions in C# is another variation on this problem and it becomes yet another switch to turn off in the IDE to ensure all code is visible all the time. In theory being able to hide auto-generated code from developers when editing is a venerable goal, but the way I’ve seen it being used is to hide big chunks of code which just appears to act as a catalyst for the creation of behemoth source files.
Does this “theory” hold water? When I tweeted about it there were a few murmurs that at least supported vague anecdotal evidence and nobody came straight back and cited a paper, so I don’t think it’s already been debunked. I was pretty sure it’s old news too and amusingly I did get a reply from Len Holgate with a link to a blog post he had written almost exactly 10 years earlier that touched on part of this topic “VS.Net #Region”.
Perhaps a passer-by will leave a comment in future that will provide evidence of a more scientific study of this feature. Or alternatively someone else will point out how the tools being used incorrectly so that I don’t feel the need to turn it off the moment I install Visual Studio.
 You can read that as “a handful of cases”.
 That’s the name used in Visual Studio, but I have also heard the term “folding editor” used for the same feature.