Thanks to both you and Cetin for bringing this up.

I'd say it's time to get magazine publishers to change their requirements! All their current practises are achieving is to perpetuate BAD HABITS. Much like VFP sample code does.

Since more and more people are relying on magazines - both printed and online - rather than Microsoft for good "documentation" it is almost an imperative that they change to allow top-quality code to be shown in all examples. Even if they have to allow a paragraph extra to 'explain' the conventions of the code.

cheers


>>>PS: No matter what I say, in my code (especially the ones posted here) there is scope and type identifiers. Not for I like them but becasue majority of users seem to understand and use them better vs the ones w/o those prefixes.
>>
>>Interesting point. I'll bet even if all editors and writers of FoxPro Advisor and FoxTalk are convinced that throwing away the redundant prefix is a good thing, the existing convention will still be followed in all the code published. <g>
>>
>Having written recently for FT, this is a painful topic. In my own code, I've always been a big believer in "m." (for reasons stated by Christof in a different branch of this tree). Similarly, I'm a believer in using sufficiently long variable names to give the developer a chance of understanding variable usage.
>
>Now, try translating code that complies with both of these into a publishing medium with 56-character line lengths and limited article space. You're suddenly faced with tradeoffs between including "m." and longer var names, and needing to truncate code or text of your article because each of those force you to word-wrap your code. In fact, even word-wrapping the code can introduce errors and/or need to re-test stuff that is already working.
>
>If the article is not about these topics, this isn't a trivial choice. And you can't publish a disclaimer stating "really my actual code is higher quality, so don't assume I don't know what I'm doing and discount the article".
>
>-- Randy