>>However, short of syntax highlighting, I find mdot the best visual identifier for variables. Call it a preference, if you don't want to start a religious war ;-)

At the age of 15 I became fascinated by a 4GL with only 4 variable types: 16-bit integer, single or double-precision floating point, and string. Variables could be strongly typed:

DEFINT [pattern]
DEFSNG [pattern]
DEFDBL [pattern]
DEFSTR [pattern]

or you could use a $ suffix to denote a string, with other undefined variables defaulting to integer from memory. No boolean, though integer 0/1 worked as expected with AND OR = etc. Dates could be stored as strings, integer offsets from a start date or single precision if you needed more than 65535 day ranges.

Varnames were kept short, since most machines had 16K RAM and some had only 4K. A$ was commonly seen as was integer N in a loop. 4K was still a lot compared to the 128 bytes available for Moon Lander on a PDP. ;-)

Years later, FP2's lack of line numbers, rigid construct management or a varname convention did seem less disciplined. It's worth remembering that FP2 didn't yet have the 32-bit integer field type so some care was needed to avoid floating point math errors on numeric data. So while anybody could claim the pilot's seat, some care was needed to get it into the air safely. I expect that many converts to FP2 came from backgrounds with variable naming conventions, with FP allowing just about any convention to be transplanted. Which is what happened.

Also, "optimistic locking" in those days was mimicked by SCATTERing the table to varnames to be used on edit screens, so the user never was editing actual live data before she decided to cancel. Instead the values were GATHERED when she elected to save. In this case, distinguishing variable from same-named field in the selected table was a must and mdashgreaterthan and then mdot was very familiar to everybody using this technique. While it fell out of favor with the arrival of Remote/Local Views and HN, it wasn't long before Fox gurus verified performance reasons to continue use. As per previous, IMHO it's no great hardship compared to enforced dataset prefixes in many (most?) other languages.

So, no religious wars here. My only definite hard dislike, is over-complicated code that may amuse its developer but is a nightmare to maintain. That's true whatever language you use, though VFP's OO and even SET PROC makes it easy for a Rube Goldberg to create vast nested labyrinths that nobody can maintain easily, not even the author!