>I find most .NET language programmers avoid our Foxpro habit of indicating data type with a prefix. I guess with strong typing and intellisense it is a lot less necessary.
>
>By now I've trained myself to avoid using type, class, object etc as field names of any kind. Just more trouble than it is worth. ( broke the "class" habit in VFP as I was writing a lot of school software - started using "course" ) Best way seems to be to extend the word - ActionType, AcademicClass etc.

Thanks

For each property and variable, I need to know the type. Anyone who would omit that would not work that long for me. lol There is nothing worst than reading someone's code and not understand what is the type of the property or the variable we are using. Also, as oppose to VFP, when you look at most .NET examples on the net, you will find variable such as i, j, myrow, my, etc. Outch, if I want to use a counter representation, I will use lnCounter, where "l" represents local, which means it is not a property of the class but a variable and "n" for numeric. It is not perfect as everyone can use his or her own naming convention. But, the most important is to have one. I still use this kind of reverse hungarian naming convention I learned from one of YAG's class in the early '90s.

As for SQL Server, I can use anything now as my framework will add the [] between field and table names. So, this resolves the issue. It is just in the designer for those reserved words. So, when facing a reseved word, I add one additional letter so I know that I should only ignore the last character and recognize the property or variable as is.

One thing to remember is that I am working at a framework level. So, whatever I do focuses for 7 years with the ability to be adjusted into a new platform, if ever MS decides to leave .NET. They did that once with VFP. So, we never know. So, no matter what we could avoid about not using those reserved words, when comes time to switch to another plateform, we are facing new reserved words and such.

I agree with the extension. This is what I do. When I train, I tell people, those who are too lazy to type, to avoid using a property named FrstNam instead FirstName or ExpDatForStat instead of ExpirationDateForStatus. That is of course in the sense of a field name. For those, I do not add the type nor any "s" at the end as it just confuses developers and makes it harder to remember if a specific field has the "s" or not at the end. So, when being used as a property it would be cFirstName and dExpirationDateForStatus and when being used as a variable, it would be lcFirstName and ldExpirationDateForStatus.

As I said, the goal is to have a convention that everyone in the team agrees on. As, I have been in so many environments where everyone wants to use their own that I just ran away like hell from that place. lol