>>There's a time and place for everything. Moving all code under every circumstance out of a button's click() event, and only ever calling method code, is going to an inappropriate extreme in my opinion. It's like using "m." prefixes on everything. It clutters up the code to such an extent that I would advise against using it. In my 32+ years of using Fox-base software, I've only ever had one name collisions where I could've benefited from using m., and it was a fluke thing that would've been corrected with properly named fields and variables anyway.
>
>More bad advice. Using m. consistently means your code doesn't depend on a naming convention (and incidentally, runs faster). Using it only sometimes means the next person to read your code has to try to figure out why you did it that way sometimes and why you didn't at other times.
>
>I try to write code that the next person who has to work with it can understand without having to get into my brain (and, for that matter, that I can come back to years later and understand without a huge effort). Standards help. Doing things the way the language was designed helps.
>
>Maybe you're the only one who works on your code and you don't inherit code from others. I've made a career of taking over other people's code and expect that I'm leaving code behind when I retire. So I've seen really good code and really bad code, and I'm trying to ensure that what I leave is really good code.
>
>Tamar

Using m. is really important, especially when dealing with inherited projects and third party tools. Just today I had a situation where I used Marcos nfJsonRead() function and it crashed under certain cases. After at least one hour of debugging and trials it turns out this legacy app has a table called OBJ, and nfJsonRead has an object variable called obj which is sometimes referenced with and sometimes without m.

I was lucky that I did get the error in develop, because the OBJ table is not always open. Therefore this error could have easily been distributed to end clients, with errormessages that would be really difficult to trace. In that case I would estimate that the time lost would have been close to one working day.

Now I would never have called a table OBJ, neither a variable, but when dealing with projects of other people you can never be sure what you may encounter.