A best practise is to use FxCop for a static code compliance. This tool enforces many rules. Some are performance-related; others are security standards while others are just considered industry-standard best-practices. One area that is enforced and has become an industry standard, is to use a specific combination of camel-case notation for source code. This is the standard in Java, some C++, some XML and now in .NET languages.
- Common Standards
Any developer who came up through VB6, might note that Microsoft endorsed “Hungarian notation†for source code up until VB6. Although that was the standard, once Microsoft expanded in the Object Oriented arena, many short-comings were discovered with Hungarian notation, and now that thinking is abandoned.
a.)Hungarian Notation
Hungarian notation is the methodology of using typically a 3-character prefix on a variable name to signify something about the data type. For example:
Dim strUserName As String
Dim intCount As Integer
Dim lngNumOfRecords As Long
Dim arrItems As Array
This worked well when there weren’t that many data types. In .NET, using custom data structures and having far, far more types available in the .NET runtime – starts to render this method less useful. For example, consider these type names:
Dim uddUserDetail As _
New UserDetailDataForm()
Dim cmnCommon As _
New Common()
Dim ccrClaim As _
New CustomerClaimReference()
As the developer starts dealing with non-standard and custom data types, this notation becomes less useful. But worse, is that developers across a project might use different prefixes, which further de-values the prefix. In addition to all of this, intellisense has come so far that all a developer need do, is hover the mouse over the keyword and basic information is displayed.
What should be used instead then? Well, there are some more specific rules on this – but generally, full names should be used. Avoid abbreviations and shortening names. For example:
Dim userDetail As _
New UserDetailDataForm()
Dim _common As _
New Common()
Dim claimReference As _
New CustomerClaimReference()
b.)Camel-Case Notation
Camel-case is the general term for using lowercase letters except for the starting letter of a word. For example: ThisIsCamelCase and thisIsAlso. More commonly, when the first character is lowercase, but the rest follows this rule – that is commonly called camel-case.
c.)Pascal-Case Notation
Pascal-case is a specific version of camel-case notation. Pascal-case defines that the first character of every word is capitalized. For example: GetUserDetail or FirstName.
When you use FxCop as a static code analysis and compliance tool, it is looking for a specific formula for naming standards of class members and arguments. Here is a summary:
Use Pascal-Case for (EveryFirstLetterCapitalized):
• Class names
• Public members (properties, methods, events, fields, delegates, structs)
Use Camel-Case for (allButTheFirstWord):
• Non-public members (properties, methods, events, fields, delegates, structs)
• Arguments in methods, events, delegates
VB.NET is one of the few non-compliant CLS (common language specification) languages. That generally means that it doesn’t respect case-sensitivity. This does throw a kink into this ruleset. Because in C#, you might have code like below. In a CLS compliant language, there is a different between firstName and FirstName. In VB.NET, there is no difference. So although the following C# code is valid, you must work around this in VB.NET. This is typically done by keeping the same naming standard, but giving private members an underscore prefix. For example:
C#:
private string firstName;
public string FirstName
{
get { return firstName;}
set { firstName = value;}
}
VB:
Private _firstName As String
Public Property FirstName() As String
Get
Return _firstName
End Get
Set(ByVal value As String)
_firstName = value
End Set
End Property
References:
MSDN: Recommended coding practices for .NET
Common Language Infrastructure
Writing CLS compliant code
Common Language Specification
MSDN: Use entire words or syllables
MSDN: Use mixed case without underscores
MSDN: Use consistent terminology