Alright, drop out then. <g> I am ready for it to end. It's actually quite far off-topic. My replies are scattered, too . . .

>Russell,
>I actually prefer technical things more and now I am sorry to be caught in a mess discussion:) See my replies scattered:
>
>
>>Hey, I think I may have chimed in on at least one of those threads to support you. <g> That's probably one of those good ideas I seem to remember you having around here. <g>
>
>If that is why you remember me (Hungarian notation or not and alike) then I would be sorry about the time I spent contributing to VFP community for years.

I said "one of those good ideas", not the only one. This was just one I happened to remember since we were talking about it. I've seen you around a lot, so don't despair all the time you spent. It was well-spent time and I'm sure many people appreciate your input.

>>My methods/variables would be like this:
>>
>>TotalCount (a variable)
>>AcctNum (a variable)
>>
>>No m. -- I dropped that a long time ago.
>>
>
>No m. :))))) You should certainly remember me for this one as one of strongest defenders of the idea "m. should be used".

I used to do it long ago. It seems to me that most VFP developers dropped it, though. I have no statistics on that, however.


>>CalcSqYds (a method)
>
>
>Why TotalCount, AcctNum are variables but CalcSqYds is a method? Because the latter is more cryptic? Looks like you combine case-sensitivity with crypting ( and still say case-sensitivity is bad:)

I didn't think any of them were cryptic. CalcSqYds is just short for CalculateSquareYards, using pretty standard abbreviations. I never said I didn't use mixed case. I do. It makes for better readability. However, if I have a field named acct_num and sometimes put it in code as acct_num and sometimes Acct_Num, I don't want a compiler/interpreter thinking those are two different things. It's not consistent capitalization on my part, but I don't feel that the case of a var/field/method/whatever should matter.