C# here...

Normally, for member variables, we use camel case prefixed with underscore. For example:

private int _counter;

However, we make an exception for controls on WinForms. Mainly because the _camelCase looks weird in the designer. After much internal debate without a strong madate either way, we eventually decided on "hungarian-like" notation. We don't use strict hungarian notation and we don't abbrivate the prefix as much. For example, we would use:

textUsername
labelUsername

This won out over simple camel case (without the underscore) by a couple votes. The arguments that pushed it over the edge seemed to be that

a) you could easily tell the control type in the drop down in the designer (whereas the datatype that is included in the drop down UI is sometimes truncated before the interesting part)

b) controls of the same time sorted together. Some people liked all their labels to be together and all the text boxes together, etc.

I prefer lblUsername as it makes it apparent that you are dealing with a user interface control instead of another type of variable like a string, integer etc that gets passed around more often. Pure hungarian is too long for my taste so we shorten it up a bit within reason so you don't get collisions.

The biggest "issue" with this is if you name similar controls (say you have an Edit and a NumberEdit and a SpinEdit) with different prefixes (say e, ne, and se respectively.) If you want to change the control type you have to go fix the references all over the place. Solution: similar controls get the same prefix (if it looks like an Edit, be it a SpinEdit or other, it gets the e prefix.)

For windows forms controls I will use Hungarian notation (lblSomething), but that's about it. For everything else I use a CamelCase name. For example:

string username = txtUsername.Text;

I tried going with camel for all my variable names (as perscribed in MS's best practices I believe), but couldn't get used to it.

Well old habits die hard. I used to use Hungarian for several years. But with VS hungarian isn't needed anymore. But Hard Habit to break.

However FxCop does check to make sure your using good Camel Case, so since initial release of .net 1.0 I have been trying to alway do correct Camel but every now and then when your deep lost in thought and the code is just flowing. FxCop will still catch a hungarian in there somewhere.

Member variables: I prefix with m_ then camel cased, but no indication of what type it is. ex: m_userName

Method parameters: camel cased, userName

Variables: camel cased, userName

Properties: pascal cased UserName

Control declarations: Hungarian with a mixture of Camel cased, lblUserName

We use Hungarian in the last because in web / windows apps, we can have a Label & Textbox all relating to a User Name, but if we just have userName, which one is it? To us, it makes sense, it also gives us an idea of what we're working with too. However, all other variables (I feel) shouldn't follow this method, because you can easily find out using intellisense, debugger, or just scrolling up a bit.

This is sure to make several folks cringe...

We are using mostly Pascal, because that matches the column names in the underlying tables. A TextBox would be "Username", and the label which names it would be "UsernameLabel".

It greatly simplfies questions asked regarding forms or reports, such as "where does this data come from"? No need to trace through layers of business logic, etc. in most cases.

In our particular case, the translation for "Username" is also derived from the control name. The end result is that all instances of "Username" will be named the same - with a form level override possible, of course.

my reasoning for supporting the death of hungarian notation is that code should be refactored to a level that its self-describing and you don't need to look at naming conventions to derive meaning.

And for camel vs pascal, just follow microsoft's design guidelines. seems to be the popular answer too ..yay!

I used double underscores and pascal case, e.g. __UserName or __Password

I see little use for hungarian because the VS.Net will let me know what kind of control it exactly is (and it saves typing)

Controls is the only place whether I use Hungarian notation. Here's why:

Controls often come in pairs. Each text box, combo box, or grid usually is accompanied by a label. The prefix makes it easy to name the label control and to distinguish it from the control it labels.

For instance:

txtUserName + lblUserName
cboOrderType + lblOrderType
grdOrders + lblOrders

Nowadays, I use Label_UserName or DropDown_Option1. Still conveys the idea of hungarian notation separation, but who cares about variable name lengths anynore? Hungarian came about because space used to be a a precious commodity.

I camel-case my private variables, prefixed by an underscore -- so, _myVariable. Since controls are just private variables, I do the same for them: TextBox _lastName etc. The type is always visible via the editor / debugger, if I forget.

If a control is visible publicly (or set to internal), I PascalCase the name: internal TextBox UserName;

Ditto what Matt Hawley says above.

It's a good question. One of the things I dislike though is seeing:

string strUsername = txtUsername.Text;

Look at the redundancy in those names!

I'd prefer something like:

string username = usernameInput.text;

maybe using input to remind the reader that this is a user edited field. I'm happy for better suggestions though!

Hungarian here. I first started coding with VB and the book I learned from used Hungarian and it's stuck with me as a very logical naming convention.

I just realized that I don't, however, do that with database fields...

I am a Hungarian when it comes to naming controls. It is a holdover from the old VB/VBA days.