>>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'm on this one with Rick. The m.dot is not what I prefer to use. The code readability indeed suffers from it. Like Rick, I'm avoiding naming conflicts as fields will have prefixes that will not conflict with variable names. This problem we are trying to avoid, in practice never has been a problem for me

The speed advantage is very circumstancial. First of all it must involve a selected table with significant number fields in it and second it must have a large number of variables to go through before it becomes measurable, let aside noticable.

The are places where you cannot use m.dot (e.g macro substitusion) and situations where you should not (like m.THISFORM, m.THIS)

unfortunately a VFP programmer has to be aware of naming conficts, esspecially with keywords (Try to use a field named THISFORM, THIS or THISFORMSET) so avoiding clonflict is something a VFP has to grow by nature. To me its a non-discussion which has been held many, many times up here. To me its irrelevant, and sometimes even gives you a false sense of safety as there is not a lot of code out there that is very consistent with that (e.g. look arround at github). I doubt even more than 10 percent of all code written by m.dot adopters has no errors in applying the m.dot consistently.

I don't care whether you are using it or not, but I can't see any merit in it as long as you avoid the issue of naming conflicts.

>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.

We all want to write code that someone else can understand. I fail to see how mdot fits in there. It does not make your code more readable if the writer applied common sense in naming conventions.

>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.

That is a challenge for life. I hate my code of 5 or 10 years ago and I'm sure its about the same for many of us. That is why we refactor code. I've been through a lot of code from others, and sharing with others as well. Writing good code goes way beyond mdot or even formatting. Writing the best code is something of an art which not many are skilled with.

Walter,