>>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 never use it. I find it so visually cluttering that it makes code impossible to read. When I get code from someone that has m. prefixes everywhere, I find/replace them with SPACE(0) so they go away.

And as I said, in 32+ years of development, only one case where there was a name collision, and that one came from using irresponsible naming conventions.

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

Like putting code in object events? :-)

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

Multiple developers.

I've learned over time that so long as people code to a reasonable standard, no matter what that standard is, the code is maintainable, and the developers coming along afterward are able to maintain the code.

I've never understood the m. philosophy. I understand it removes uncertainty, makes the code go faster, etc., but it is so visually cluttering as to make the code unreadable IMO. I would sooner live with the uncertainty, and deal with the slower code, than clutter up my source code with such prefixes. VFP is so fast and capable that it's just not an issue IMO. 32+ years of writing I don't know how much code, probably several hundred thousand lines at least, maybe millions of lines, and only one issue ever with a name collision, and that wouldn't happen today with intelligent variable and field names.

It was such a thing for me that I introduced into Visual FreePro, Jr. a setting to allow a software extension to make VFP look to memory variables first when trying to find names, so that m. prefixes could be safely removed, and then you only needed to prefix aliases if you wanted to. That approach seems more appropriate than requiring m. prefixes on memory variables.

You and I will never agree on this matter. I'm content to agree to disagree. I respect your abilities and knowledge and accomplishments greatly. The papers you've written I've read have been excellent. I've learned much from them. I would advise people to use your services without hesitation because they are part of a system that is one that works. But I do disagree with your views on several things, and I also have a history of success in development to back up my positions on things.

VFP is flexible and powerful enough to allow multiple philosophies to accomplish the same things, each with various constraints, requirements, relaxations, benefits, and pitfalls. It's why I wanted to create Visual FreePro. I hate to see VFP fade into history. It is such a powerful tool, and with very few extensions it could've become the de facto developer language for all time. It could've replaced .NET by adding some lower-level C/C++ like abilities. It could've been on the A-list for as long as we have programming languages. I still have plans to complete Visual FreePro. It's still on my short list of most desired goals.