Pete Brown's irritatedVowel.com
   home    wallpaper    railroad    .net, c#/vb    photography    birds    psp tubes    home/wood projects    games    recipes  
about   |   privacy   |   guestbook   |   pete's blog          
AddThis Social Bookmark Button

Section Contents
Naming Conventions and Standards
Best Practices
Links
Demos
HTTPModule Example
ASP.Net Cache API
AddThis Social Bookmark Button

.NET Best Practices

A Few Best Practices

There are tons of best practices for .NET development. I have a few documented here for convenience.

VB.NET : Declaring Namespaces in Visual Basic .NET

Did you know that the value in the project property "Root Namespace" is prepended to any namespace you explicitely declare in your code? This is in contrast to the "Default Namespace" property in C#.

In Visual Basic .NET, the root namespace is set to the project name by default. If your project name contains only one namespace, and follows the assembly naming convention detailed above, your namespaces will be all in order. If, however, you have a different naming convention for your assemblies due to company policy or due to the fact that the assembly contains more than one namespace, or only a partial namespace, this will foul up your assembly namespace.

For example, if your assembly is named "MyCoBusinessRules" and you have a namespace directive that follows the above conventions MyCompany.CoolApp The full namespace of any classes in that namespace directive will end up being MyCoBusinessRules.MyCompany.CoolApp

The most consistent way to avoid this is to simply blank out the "root namespace" project propery and instead explicitely declare your entire namespace using the Begin Namespace directive. This will make the namespace obvious to other developers on the project, avoid problems with tools such as Rational XDE and other code generation tools, and also bring you in line with the standards and practices as used in C# and other .NET languages.

VB.NET : Option Strict

One of the best things you can do to pull your Visual Basic.NET code out of the VB6 dark ages, is to ensure that Option Strict is on in all of your class files.

When Option Strict is on, you are required to explicitely covert between normally incompatible datatypes instead of requiring the compiler to make a possibly incorrect guess as to what types of conversions you want to do.

An example of that is the expression fragement :

"3" + 5

Do you want that to evaluate to the number 8, or a string containing "35"? If option strict is on, you need to either convert the 5 to a string using CType(), CStr(), ToString(), etc. or you need to convert the "3" to an integer using Integer.Parse(), CInt(), etc.

C# .NET : The "Using" Statement and IDisposable

A cardinal rule of .NET resource acquisition and release is this : If an object is an instantiation of a class that has a Dispose method, or implements IDisposable, you need to call Dispose as soon as you are done with that object.

IDisposable.Dispose() releases unmanaged resources (file handles, windows handles, database connections, etc.) that are expensive to keep around until the next garbage collection run. Note : IDisposable is not supposed to do anything with managed resources like managed objects. It simply deals with unmanaged resources.

When you call the dispose method, what typically happens is the unmanaged resources are released, and the Finalizer for that instance of the class is suppressed. This is a nice performance optimization as Finalization can be costly, especially if you have a large number of objects waiting to be finalized.

If you do not call the dispose method, what typically happens is the garbage collector tries to collect your object, and sees that it has a finalizer that must be called. It is then put on a finalization queue. When the finalizer is run the object can then be collected and the memory returned back to the pool.

C# has a nice statement that automates dealing with the Dispose method. You can use this statement with any class that implements IDisposable. If the class does not implement IDisposable, you will get a compile error

using (MyClass myClass = new MyClass())
{
    // do something with myClass
}

The above C# code is equivalent to:

MyClass myClass = new MyClass() ;

try
{
    // do something with myClass
}
finally
{
    myClass.Dispose() ;
}

As you can see, Dispose will always be called, even in the case of an exception.

You can nest using statements and you can include multiple comma-separated instantiations in the parantheses.

Most folks will run into Dispose with ADO .NET and also with streams. 

who's online