Why Should You Use The C# Predefined Types Rather Than The Aliases In The System Namespace

In the "C# Coding Standard" by Juval Lowy available from www.idesign.net, the recomendation is made to use the C# prede开发者_开发问答fined types instead of the aliases in the System namespace, e.g.:

• object NOT Object
• string NOT String
• int NOT Int32

What is the benefit of this? How do they differ? I have followed this advise in my own coding but never knew how they differed.

The main time they are unexpectedly different is when someone is stupid enough to call a type (or property /field/etc) String (for example), since string always refers to global::System.String, where-as String could be YourNamespace.String.

The closest you can get to the C# alias is @string, which tends to stick out like a sore thumb.

I prefer the C# aliases.

btw, here's a fun way to mess with anyone using dynamic too much:

using dynamic = System.Object;

They don't really differ. Personally I use the aliases too, but Jeff Richter advocates the exact opposite. The generated code will be exactly the same. Use whichever you find most readable (and try to be consistent).

One thing most people agree on: when writing an API, use the type name rather than the alias, so:

int ReadInt32()

rather than

int ReadInt()

the int part doesn't matter here - it's not part of the name, and can be displayed appropriately to any consumer using any language... but the method name should be language-neutral, which means using the type name.

One place where you have to use the alias is when specifying the underlying type for an enum:

enum Foo : byte // Valid

enum Foo : System.Byte // Invalid

In addition to what Jon said here is another difference.

var x = (Int32)-y;    // Does not compile.

var x = (int)-y;      // Negates the value of y and casts as an int.

This is because of a grammar disambiguation rule defined in §7.6.6 of the C# Programming Language specification.

I think using the 'blue' int, string, etc.. might be a little more intuitive to read. Otherwise, I use the class when calling a static method on it i.e. Int32.TryParse()

I always use the aliases when specifying the type in a parameter, property or method signature or field (so: almost everywhere) except when calling a static member on such a type.

String.Format("{0}", 1);
Int32.Parse("123");
String.IsNullOrEmpty(value);

Here's another compiler-based difference:

public enum MyEnum : Byte {Value1, Value2} //does not compile

public enum MyEnum : byte {Value1, Value2} //ok

The only difference is that they're nicer to read (this of course is a matter of opinion). The compiled result is exactly the same bytecode.

The Entity Framework code generator uses predefined types, so if you want to be able to implement the Visual Studio 2017 coding style rules fully you will need to choose predefined types (int instead of Int32, etc). Otherwise your generated code will not be in compliance.

(Options->Text Editor->C#->Code Style->General->predefined type preference)