Deedback on .NET Coding Best Practices

[Rasika Wijayaratne]

Hello,

Can I get feedback on these .NET coding best practices please. Thanks
to Konrad Rudolph and Jon Skeet for the replies to my previous post on
'Writing Properties.' Thanks in advance to all replies to this post as
well, as I am having probs posting from MS Communities site (posting
from Google).
===========

Avoid Returning null Instead of Array, String, or Collection

In almost all situations except when performance can be an issue (e.g.
heavily looped or performance tuned code), null should not be returned
from a method that returns an array, string, collections, ArrayList,
BitArray, HashTable, Queue, SortedList, or Stack. It should not be
necessary for a user of a method to handle a null that is returned
from a method. Instead only empty or zero-length data types such as 0
item arrays, empty strings (String.Empty), and 0 item collections
should be returned.


Avoid Checking String Equality Using == and = Operators

Using == operator in C# and = operator in Visual Basic to compare
strings is slower than using the System.String.Equals method. In
addition, if you need to do case sensitive or insensitive comparisons
the System.String.Compare method is the preferred way to do so. The
String.Compare method can compare two strings based on their
alphabetical sort order as well, something that is important in
developing applications for the international market.


Testing for Empty Strings

The most efficient method to determine if a string is empty is via
it's Length property.

[C#]
if(var1.Length < 1)

[Visual Basic]
If (var1.Length < 1) Then


Avoid Hard Coded String Literals

Use String.Empty rather than "" for empty strings. Other strings
should be placed in a constants class.
[C#]
string var1 = ""; // Avoid
string var2 = String.Empty; // Recommended

[Visual Basic]
Dim var1 As String = "" ' Avoid
Dim var2 As String = String.Empty ' Recommended

 

[Jon Skeet [C# MVP]]

Avoid Returning null Instead of Array, String, or Collection

In almost all situations except when performance can be an issue (e.g.
heavily looped or performance tuned code), null should not be returned
from a method that returns an array, string, collections, ArrayList,
BitArray, HashTable, Queue, SortedList, or Stack. It should not be
necessary for a user of a method to handle a null that is returned
from a method. Instead only empty or zero-length data types such as 0
item arrays, empty strings (String.Empty), and 0 item collections
should be returned.

That really depends on the meaning of the method. For some operations,
like "Find all matching elements" it makes sense to return an empty
array or collection. For others, it makes sense to return null. It's
certainly worth always *considering* it, but it's not really something
to avoid as such.

Avoid Checking String Equality Using == and = Operators

Using == operator in C# and = operator in Visual Basic to compare
strings is slower than using the System.String.Equals method.

Do you have benchmarks to back this up? I'd expect them to be identical
in speed, after the JIT had inlined the call to == to be just
String.Equals(a, b). It's also less readable (IMO) to use Equals than
==.

Testing for Empty Strings

The most efficient method to determine if a string is empty is via
it's Length property.

[C#]
if(var1.Length < 1)

I suspect that

if (var1.Length==0)

is actually more efficient the < 1 test, although I haven't tested it.
It's clearer in meaning, however (IMO).

Avoid Hard Coded String Literals

Use String.Empty rather than "" for empty strings.

Why? I see no reason for this.

Other strings should be placed in a constants class.

Rather than having a single constants class, constants should be
declared appropriately within their domain. For instance, you would
place SQL column names etc within database-domain classes, but you
wouldn't want to mix them with literals to do with completely different
concepts.

I don't see anything wrong with having some hard-coded string literals
in the middle of the code though. If you're only going to use a string
once (eg for a SQL query) there's little point in making it a constant.

User interface strings should usually end up as resources, one way or
another, to allow for internationalisation.