In general we are adopting Microsoft's suggested practices in MSDN (Design
Guidelines for Class Library Developers). But there are a few special cases
that aren't directly covered in those guidelines, and there also seems to be
some inconsistency in what Microsoft suggests.  I'm looking for some
opinions:

1. Hungarian notation -  Microsoft's Capitalization Styles suggests using
Pascal case for static fields, but their Static Field Naming Guidelines
section suggests using Pascal case WITH Hungarian notation.  Which is more
correct or more accepted?

2. Underscores for static fields - our team is considering adding an
underscore in front of Static field names.  The intention would be to easily
denote which variables are within class-level scope.  MS's guidelines make
no mention of using underscores.  I have seen underscores and Camel case for
static fields before.  MS's guidelines strictly suggest using Pascal case
for static fields.

3. Identification of controls - if not using Hungarian notation, it would be
nice to be able to identify control types in static field names.  I haven't
seen any recommendation on this.  Example:  I have a form with a Label
control and a TextBox control.  The Label's text is "First Name:" and the
textbox is used by the user to enter their first name.  To me, it would make
sense to name these controls FirstNameLabel and FirstNameTextBox.  Or if
using the underscore:  _firstNameLabel and _firstNameTextBox.  My problem
with using this convention is that long control names take more time to type
(e.g.  _stateDropDownList).  Hungarian notation would shorten these names up
quite a bit:  lblFirstName, txtFirstName, drpState.

Any suggestions?  My goal is to adopt a convention that is intuitive, easy
to read, and easy to understand.  A smaller goal is to conform to other
practices in the developer community.

- Mike

Replace static fields with property definitions, use Pascal case in this
case ("FileName", "EndDate", etc.).

General rule: No prefix (except "I" for Interfaces), type prefix, and
Camel case for elements which are part of the object interface. Local
variables can use Camel case (*ugly*).

In my opinition this doesn't make any sense. If you create a class that
derives from a control (e.g. TextBox, it can be called
"ExtendedTextBox", a class extending Form will be called "MainForm",
"SetupForm", and so on).

When writing code you often don't know the control's exact name. When
naming controls with a type prefix ("lbl", "txt", etc.) it's easier to
locate them in the intellisense box (you type "lbl" and see all label
controls grouped).

Regards,
Herfried K. Wagner

do something that's sensible for your shop; developers always push back at
the unfamiliar; they also adapt pretty quickly ...