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.

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


>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:)


>
>Sometimes my method names will get quite long:
>
>AdjustSampleRcptNotification, SetTestCodeMultiSampleStatus, probably I have some longer ones. Maybe we should have a contest for the longest method name. I might be in the top five. <g>

That is fine and perfectly acceptable. Even during fox 1, 2.x I remember I was doing some paradox programming and happy to have 32 characters procedure names.

>
>However, with field names I have been inconsistent. Sometimes I might write it as Cust_Name and other times cust_name. But this is a minor thing to me. I strive for more consistency with that these days, but as far as good code goes, I think that is very low on the list of issues, if it's there at all. There are many, many more imporant things on the list above this issue that make for good code (or not).

Yes, good code depends on many things.

Cetin