The Hungarian naming convention pertains to all identifiers you will use in your programming to enable tying the type of identifier to the identifier’s name. These make your life very simple when adhered. The prime benefit of this notation is that anyone who is looking at your code and is familiar with that notation can now tell a lot about the variable without going back to the definition or declaration of that variable.

NOTE: The Use of underscores undermines the purpose of camel case and should be strictly avoided except at the beginning of a variable or identifier as shown below.

As mentioned before, always precede private members of a class with an underscore.

Example:

private Variable _myOwnLittleVariable = null; 

private int _nInteger = 0;

private long _lLong = 0L;

where Variable is a class.

For local variables, prefix the type into the variable name.

Example:

String strTemp = String.Empty;

DateTime dtTemp = System.DateTime.Now;

Int32 nTemp = 0;

Int64 lTemp = 0L;

When you follow this standard, it will make it easier to read sections of code where these variables are manipulated without going to the actual declaration section.

Namespaces are the most important part of a development team that is emphasizing on the use of Class Libraries to achieve Modular, reusable code.

Namespaces should be organized into the following category:

CompanyName.AppDomain.FunctionalArea.Feature

Example:

Eafx.EnterpriseClasses.CommonFunctions.Encryption

Eafx.EnterpriseClasses.CommonFunctions.SecureFTP

(notice how FTP is an abbreviation and hence UPPERCASE is used)

Eafx.AutomotiveClasses.BaseEntities.Customer

The above namespace would implement all classes that relate to the Customer entity, from the Customer class itself, to classes that relate directy to the Customer class like CustomerDetails.

Note that it may always not be needed to break a namespace down to so many levels, for example:

CompanyName.AppDomain.FunctionalArea 

should suffice if you don’t foresee breaking it down further, but the bet is on that you will need to one day, and it is better to organize now than to reorganize later.

Class Names Should NOT Use the C Prefix (Bad MFC Habit). Rather, should be descriptive of what the class is desiged to do.

While the use of common nouns and adjectives is allowable, the use of a Proper Noun indicates specialization and should never done to a Generic Base Class. The very fact that you are writing a class called GMCustomer or BMWCustomer indicates that you are implementing a specialized object. One Offs are bad unless there is a Generic base class which the application consumes. (Remember extensibility). Design for the principle or concept, not the instance. There should be no Specialization without a Generalization. Therefore, any specific class that you develop should always have a generalized base class, even if you dont see the need for it then.

Examples:

CustomerAddress

CustomerVehicleInsurance

VendorService

Vendor

Interfaces should always be prefixed with an I. The rest of the Interface name can follow the same standards as a class name. (Yes, we kept this from MFC)

Examples:

IUnwanted

ISerializable

ITransaction

IVendor

Parameters that will be passed to methods as arguments should always be prefixed with a p. This will make parameters passed to other methods easier to identify and hence make the call flow more implicit.

Examples:

CustomerAddress pAddress = new CustomerAddress(pCity,pState,pZip);

Customer objCustomer = Customer.Search(pAddress);

Methods should use Verbs or Verb Phrases (with common nouns).

Examples:

DeleteCustomer()

Search()

ProcessData()

ProduceInformation()

Properties should always use Nouns or Noun Phrases (with adjectives).

Examples:

strScreenBackGroundColor

dtCustomerDateOfBirth

nCustomerAge

Common Type Prefixes
In all the above examples, you see that local variables and members that are base type instances use camel case, but the first word is usually an abbreviation used to indicate the type of the variable.

Here are some common notations that you can use to prefix your local variables. While there are too many classes that you will instantiate and use on a daily basis, to include on this list, this list is suggestive to the convention that you will use. Just ensure that you stick to a standard.

Type	Prefix	Example
sbyte	sb	sbGreen, sbRed, sbBlue
short	s	sAge, sHoursWorked
int	n	nCounter, nFleas
long	l	lCustomerId, lContentLength
byte	by	byPixel, byValue
ushort	us	usNumber
uint	un	unNumber
ulong	ui	ulNumber
float	f	fCashValue
double	d	dCashValue
bool	b	bIsEmployeeWorking
char	c	cStringCharacter