>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>This subject looks like an ideal candidate for a survey:
>>Q 1: Which of the following do you think
>>should include a letter indicating data type:
>> - Variable names.
>> - Properties.
>> - Field Names.

>All three.
>Variables should also include scope - "lc" for "local character", e.g.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Hey Trey. I actually have meant to ask your opinion of this for the past few weeks and keep forgetting -- might as well discuss it here so others can chime in. My immediate answer tot he question above, like yours, is "All 3." But lately, I have been revisiting the issue of whether or not public (i.e. exposed) properties of an object should include a naming convention.

On the one hand, of course, as you point out, naming conventions are useful in multi-developer environments for letting others know what data type is required (but that would be less important if we had strongly typed properties -- wonder if that will be available in VFP7?).

On the other hand, doesn't this fly in the face of polymorphism? Let's say I have a container, with three constituent textbox controls. To make it easier for the developers in my shop, I would like to have properties on the container that will define the enabled state and the font of all the controls. Should I call those properties ".lEnabled" and ".cFont" or should I call them "Enabled" and "Font"? The latter pair of examples certainly look more professional, and "feel" to me to be more in line with principles of object oriented design.

And in fact, base properties don't have a type identifier, so by adding one to our own (extended) set of properties, are we relegating them to second-class citizenship in our object? And if so, maybe that's not a bad thing - it might be good to see what was there already in the base language, and what I, the programmer, added.

I am undecided as of now on this matter. What are your thoughts? I think I am being influenced here by strong-typing in my VB work, in which case parameter call expected values and property enums are more readily available -- as I hope they will be in VFP 7. As a result, I see a lot more properties without type identifiers. As you well know, I tend to type-identify my properties (cSSN, nAmount) but these days I am not so certain about that approach.