Back in the DOS days, I used to use a product known as QuickSilver. Although dBASE III+ would take the following statement:
m.varname = value
and interpret correctly as assigning value to variable varname, QuickSilver would misinterpret it and create a memory variable called "m.varname"! The only way to access the resulting variable was to use m.m.varname (talk about things starting to get really ugly). Due to this oddity, I often tend to use the "m." prefix only where there is a possible ambiguity. On the left-hand-side of an assignment, there isn't an ambiguity as a variable is the only thing that makes sense here. However if there's an expression, I tend to put the prefix in front.

Speaking of syntax ambiguities... Out of habbit I prefer to use [] instead of () for addressing arrays. The usage of parenthesis doesn't make it clear if you're accessing an array or if you're calling a function. Although if used on the left-hand-side of an assignment statement it's not ambiguous, I'd prefer to be consistent. I don't exactly recall the example I gave to my co-workers on the importance of this, but it went something like the following:

program ProgA.PRG contains:

DO ProgB

DIMENSION Test(10)

Test(1) = "Hello, world"
DO TestProc
?? "ProgA:"
?? Test(1)
?

DO ProgB

RETURN

PROCEDURE TestProc
    ?? "ProgA.TestProc:"
    ?? Test(1)
    ?

Program file ProgB.PRG contains:

?? "ProgB:"
?? Test(1)
?
DO TestProc
RETURN

FUNCTION Test
    PARAMETERS xArg
    RETURN xArg

This is the output:

ProgB:          1
ProgA.TestProc:          1
ProgA.TestProc: Hello, world
ProgA: Hello, world
ProgB: Hello, world
ProgA.TestProc: Hello, world

Although the [] notation won't completely resolve this kind of problem, it does help in making clear what the intent happens to be.