Sometime in the early part of the century, think about 2004, I saw a talk which analysed source code for defects. They had used, what was at the time fairly new, online source code repositories for open source programs. They determined that a piece of code was buggy if it was changed in a commit which fixed a bug. The authors analysed the code (which was all written in Haskell) to see if they could determine differences between 'buggy' code and 'non-buggy code'. I wish I could remember the authors or the title, but I cannot.
One of their results was that a use of a variable was more likely to be in error, the further it was from the definition of that variable. Again, I cannot remember the source talk, and I cannot remember how convincing the evidence or the argument was for this. But it must have been pretty convincing at the time since it's the one thing I remember from that talk and I still remember it now the better part of two decades later.
I use this to think about re-ordering definitions in
let-in expressions. In particular I often end up with a final container (say an
Html.div) with more or less just names:
1let 2 ... 3 secondPart_A = 4 ... 5 6 secondPart_B = 7 ... 8 secondPart_C = 9 ... 10 secondPart = 11 Html.div 12 [ Attributes.id "second-part" ] 13 [ secondPart_A 14 , secondPart_B 15 , secondPart_C 16 ] 17 ... 18in 19Html.section 20  21 [ heading 22 , firstPart 23 , secondPart 24 , thirdPart 25 , footer 26 ]
Why? Well, if instead I put half of the definition of
secondPart inline within the final expression such as:
1- secondPart = 2- Html.div 3- [ Attributes.id "second-part" ] 4- [ secondPart_A 5- , secondPart_B 6- , secondPart_C 7- ] 8Html.section 9  10 [ heading 11 , firstPart 12- , secondPart 13+ , Html.div 14+ [ Attributes.id "second-part" ] 15+ [ secondPart_A 16+ , secondPart_B 17+ , secondPart_C 18+ ] 19 , thirdPart 20 , footer 21 ]
Now the uses of
secondPart_C are much further way from their definitions than they were before. I could move those definitions down, but I can only do that for one of these parts.
Anyway the point is when I'm trying to make code tidying decisions like these, one of my metrics for deciding which is better, is which keeps my variable uses closer to their definitions. In addition, where you have some large section like this, you unavoidably have some variables used quite far from their definitions. However, if you keep such uses trivial they are far less likely to be in error. So notice in my first version,
heading is necessarily far away from its definition, but the usage is trivial and highly unlikely to be in error.