4/30/2007

C# vs VB.NET Case - Sensitivity: what to do

Hegel was right when he said that we learn from history that man can never learn anything from history. -- George Bernard Shaw

This one seems to keep coming up, and basically revolves around developer misunderstanding (or more frequently, lack of knowledge) of Naming Guidelines.

The typical question often looks like the following:

"I have a class implented in a c# dll which has two different properties of same name Say "A" and "a".

Now, is their any way to use any one or both of these properties of this class in a vb.net project.because it will give the following error

Error 2 'A' is ambiguous because multiple kinds of members with this name exist in class 'ClassLibrary3.Class1'"

Yes, there is a solution: Write your classes and methods correctly in the first place!

Case Sensitivity
To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of case sensitivity:

Do not use names that require case sensitivity. Components must be fully usable from both case-sensitive and case-insensitive languages. Case-insensitive languages cannot distinguish between two names within the same context that differ only by case. Therefore, you must avoid this situation in the components or classes that you create. Do not create two namespaces with names that differ only by case. For example, a case insensitive language cannot distinguish between the following two namespace declarations:

namespace ee.cummings;
namespace Ee.Cummings;

Do not create a function with parameter names that differ only by case. The following example is incorrect.

void MyFunction(string a, string A)

Do not create a namespace with type names that differ only by case. In the following example, Point p and POINT p are inappropriate type names because they differ only by case.

System.Windows.Forms.Point p
System.Windows.Forms.POINT p

Do not create a type with property names that differ only by case. In the following example, int Color and int COLOR are inappropriate property names because they differ only by case.

int Color {get, set}
int COLOR {get, set}

Do not create a type with method names that differ only by case. In the following example, calculate and Calculate are inappropriate method names because they differ only by case.

void calculate()
void Calculate()

There! That wasn't so hard, was it?