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

I see two issues really.
(a) Whether hungarian notation is really a good idea or not.
(b) Whether, even if you decide that it is, you should use it.

On (a):
Hungarian notation is arguably useful in a non-strongly typed language. But .NET *is* strongly typed.
Within .NET, AFAICS, it could be argued that hungarian notation *might* make your code more readable if it is in print (a book or on the web).
If you are looking at it in the IDE then hungarian notation just gets in the way. Intellisense will tell you the exact type unambiguously and accurately.

On (b):
Your definition of 'everyone' appears to be 'everyone in the team' not 'everyone using VB.NET'. If you are not following the MS guidelines (whether you like them or not) it is likely that any new members to your team are going to spend a lot of time learning your team specific conventions.