>>No, unless you consider not using mdot a trick
LOL, and agreed! I'm sitting here remembering the good old days when it made sense to be able to drop the table alias in exchange for the small price of having to use m-> for the same-named variable that many of us relied upon for optimistic locking using SCATTER/GATHER. We all knew to distinguish carefully. m-> still works, fwiw. Remote Views mostly eliminated the need for SCATTER/GATHER optimistic locking, then came the ability to SCATTER into an object, we got longer variable names, CamelCase arrived... and still the concept of m-> or m. lurked deep down to catch people out. ;-)
In addition to the identified tricks, I'd say that using a,b,c variables or field names isn't necessary unless you're wanting to obfuscate. We had to do it with TRS Basic in the 1980s when a user might have only 4K memory, but it's never been a virtue in Fox IME- unless perhaps you do very complicated SQL and approached the SQL length limit. I'd heard it said that there can be a slight performance issue with very long variable names, but I've never seen a compelling measured performance hit. Use of descriptive variable names can provide context so that a good practitioner almost certainly could recommend a better way to reach the result seen here...
"... They ne'er cared for us
yet: suffer us to famish, and their store-houses
crammed with grain; make edicts for usury, to
support usurers; repeal daily any wholesome act
established against the rich, and provide more
piercing statutes daily, to chain up and restrain
the poor. If the wars eat us not up, they will; and
there's all the love they bear us."
-- Shakespeare: Coriolanus, Act 1, scene 1