>>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.
>
>It sounded something about Calcium... to me. You see it is "not only casing" but also other factors like the words/abbreviations you are accustomed to as well. The metrics we use are different too it wouldn't seem as SquareYards to me (well I would create a method likely named CalculateArea where yards would be an enumeration member instead but that is me). You should still notice that you are not only using case-sensitivity yourself but also adding English grammar in your naming (verbs for methods, noun for variables ...). When a language makes some of those rules (that you are implying in your coding) mandatory in its syntax then I would call it enforcing consistency.
>
>My last comment:
>
>If you have data in that field say "ABC Company" and you search for Acct_Num = "abc company" VFP wouldn't find it while the other backends that support case insensitivity do. Now wouldn't you think that VFP itself is case-sensitive not in the syntax but in what it does most:)
>
>Cetin

Well, your last comment sure did open up a can of worms. Case sensitivity in the source code and case sensitivity in the data are two entirely different things. You have to respect case in the data and VFP does that. All other backends that I am aware of do that, also. I don't know of any data engine that is case insensitive. Without case sensitivity on the data, M$ Word couldn't have the feature where it ignores words in all caps during a spell check, assuming that they are acronyms that won't be in a std. dictionary.