string vs System.String, int vs System.Int32 : another Alias vs Type Name question

Question

Quite often I see source code where language's keyword are replaced with full type names: System.String, System.Int32, System.GUID etc.

Moreover, people who do this write complete type names everywhere, making source full of such declarations:

System.Collections.Generic.List<System.Reflection.PropertyInfo> list = System.Collections.Generic.List<System.Reflection.PropertyInfo>(newSystem.Reflection.PropertyInfo[] { ... });

When I ask them why do they do this, i get wide range of answers: "It helps me avoid type names collisions", "It looks more professional", "my VS plugin does it for me automatically" etc.

I understand, sometimes writing full type names helps you avoid writing unnecessary using if you use the type one time throughout the source code file. And sometimes you need to declare a type explicitly, a great example is Threading Timer and WinForms Timer.

But if you source full of DB calls and you still write System.Data.SqlClient.SqlCommand instead of 'SqlCommand' it looks quite a bit strange for me.

What do you think? Am i right or i just don't understand something?

Thank you!

P.S. And another phenomena is writing if (0 != variable) instead of if (variable != 0).

Answer 1

The if (0 == variable) thing is a C++ convention used to protect against accidentally writing if (variable = 0), which is valid in C++ however doesn't do what's intended. Its completely unnecessary in C# as the wrong version doesn't compile, so you should use the other version instead as it reads better.

Personally I like to write as little as possible, so unless there is a namespace clash I never fully qualify things.

As for string vs String, I always use the alias (string / int) rather than the full class name, however its purely a convention - there is no runtime difference.

Answer 2

It is a bit subjective but unless your coding standard says otherwise I think removing the namespace is always better as it is less vebose and makes for easier reading. If there is a namespace collision, use a shorter alias that means something.

As to your last point, if you compare name.Equals("Paul") vs "Paul".Equals(name). They both do the same thing unless name is null. In this case, the first fails with a null exception, whilst the 2nd (correctly?) returns false.

Answer 3

For primitive data types: Duplicate questions here - C#, int or Int32? Should I care?

For non-primitive data types: The answers given are valid, especially "It helps to avoid type names collisions"

For if (0 != variable): variable is the subject to compare in the expression, it should go first. So, I would prefer if (variable != 0).

Answer 4

I don't find any of these reasons convincing. Add using statements is better.

Two minor exceptions:

• In generated code, you may see redundant namespace prefixes, but that is OK as this code is not indented to edited.
• Sometimes it is helpful to write Int32 explicitly when depend on the type being exactly 32 bits.

Answer 5

Make code as readable as possible! See also: http://en.wikipedia.org/wiki/KISS_principle

"It looks professional" is a very bad argument.

BTW, if your code is full of SQL statements, then you may want to refactor that anyway.

Answer 6

About string vs String. I try to use string, when it is that, i.e. a string of characters as in any programming language. But when it is an object (or I am referring to the String class), I try to use String.

Answer 7

I'd argue strongly against "it looks more professional", as frankly it looks the opposite to me.

That said, if I was to use a single member of a namespace in the entire source file, I might use the full name there rather than have a using.

Favouring 0 != x over x != 0 etc. does have some advantages depending on overrides of equals and a few other things. This is more commonly so in some other languages, so can be a hangover from that. It's particularly common to see people favour putting the null first, as that way it's less likely to be turned into passing null to an equality override (again, more commonly a real issue in other languages). It can also avoid accidental assignment due to a typo, though yet again this is rarely an issue in C# (unless the type you are using is bool).