>A few weeks ago I asked here about whether to use or not the m. identifier and even though I was already using it, the explainations I got here convinced me even more! However, it did not convince everybody here since many have been using Foxpro since the dos version without any problems, never using the m.
>
>However, with the update of the month, it created a bug since a variable called result was used in some code that now has a table opened in the current workarea when it's executed, and this table has a field called result !
>
>I'm rarely happy to know that there is a bug, but now, knowing why, I am :D

Sylvain,

Using M. or not using M. is almost like a religious ideology with fanatics on each side. While I do not consider the possibility of name clashes with variables and fields a bug, it makes for some interesting and hard to diagnose side effects. Fortunately there is a way to manage it with m. Personally, I use M. as I have also ran into situations where not using it has cause a conflict with a field name. I also try to always preface fieldnames with the aliasname. It makes for more typing but avoids ambiguity and makes my intent clear when reading the code.

On the other side, many would argue that you should adopt naming conventions for fields and variables and always name your variables such that there us no possibility that there could be a field of the same name. In a perfect world this might work if you control all code and data that your use, but where you are connecting to unknown data or using code from third party sources this really is not manageable and name clashes will pop up.

Some would argue that one way is faster than another for various reasons and conditions. I have found for me that using m. everywhere, right or left side of equal sign and anywhere a variable is assigned or accessed (except when a variable is used in macro substitution where m. cannot be used) has avoided conflicts, made my code more readable with negligible impact on speed of execution.

Just my 2cents.