Because abbreviations are nice when there's a shared context that is perpetually "in memory" - I don't have to think to know what LA stands for.
However, that is not the case when debugging. It is almost certainly the case for the person who wrote the code originally, but it is certainly not the case for the next person to come read it afterwards. IMO code is meant to be read, so I try to never use abbreviations (other than e.g. _i_ as a for loop index, which, given it's pervasive use, falls under the category of "shared context").
I read somewhere, "The length of a variable name should be proportional to the size of its scope".
Usually I don't have long loop bodies, so if the loop body fits in 24 lines, `i` is perfect for the index.
If I'm locking a mutex, doing something, and quickly unlocking it, `l` for the lock guard is fine.
But if it won't fit on screen, it needs a longer name.
And if there's something like a top-level `App` struct, I just call it `a` because its scope is really just `main`, even though its _lifetime_ may be the entire process.
Shouldn't you have some shared context when working on code together, even at different times? Maybe they terms of art, maybe it's a style guide, but there oughta be something.
Like, isn't it fine to change:
var basicAuthenticationController = new BasicAuthenticationController()
to:
var ctrl = new BasicAuthenticationController()
I find that if code authors do work upfront to contextualize things for me that it helps tremendously. Like do I need to know at every point that this is a BasicAuthenticationController? Or is this the basic auth module and we're always dealing w that controller? I prefer it when engineers set the table for me like that, it helps me narrow my focus to the purpose of the code.
