This project is read-only.

SA1121 - The real datatype is 'System.Int32', the alias 'int' should be discouraged.

Jul 2, 2013 at 6:52 PM
Edited Jul 15, 2013 at 10:27 PM
The argument for using 'int' instead of 'Int32' is becoming more and more irrelevant as time goes by. Portability just isn't an issue and even if it was, nothing is more portable than Int32; it's the same size on every machine. I deal with Interop all the time and it is much cleaner to see the datatypes up front rather than relying on some hidden mapping of aliases to datatypes. SA1121 is irrelevant.

Further, 'int' is not an essential part of the C# language. You could remove 'int', 'float', 'bool' and not diminish the language one iota. They may be reserved words, but they are not essential keywords and shouldn't have the same weight as 'for', 'while' and 'try'. BuiltIn Alias Types are superfluous.

There is no difference between System.DateTime and System.Double, so why does StyleCop treat them differently? They come from the same library, they are both 'primitive' datatypes, so why does SA1121 bark if I have a 'System.Double' in my code but not if I have a 'System.DateTime'? SA1121 is arbitrary.

I grant that there are some dinosaurs here who simply can't leave their C++ thinking behind. That, after all, was the reason that 'int', 'double' and 'bool' aliases were included in the language: to make adoption go more smoothly. Why do you think there is no 'datetime' keyword? Because they didn't need it to make the C++ programmers happy. These aliases are nothing more than built-in 'using' statements and reduce to 'using int = System.Int32'. The purpose was not to make the language better, but to make marketing easier. BuildIn Alias Types are training wheels.

'int', 'double', 'decimal' belong to the past. 'Int32', 'Double' and 'Decimal' are the future. We need to drop the SA1121 rule and encourage the real datatypes behind C#. The aliases have no other purpose than to obfuscate.
Jul 3, 2013 at 4:16 PM
I certainly agree that the primitive type aliases are a relic of the past and I do give several reasons why I recommend avoiding them in my CLR via C# book. Perhaps the biggest reason is that many C# developers forget about other languages and end up putting C#-specific types names in APIs accessible from other languages. Even developers on the .NET team have made this mistake. Example: System.Array has a LongLength property with returns an Int64 and so this method should be called Int64Length. A C++ developer calling this method, can't put the result of LongLength into a long because, in C++ a long is a 32-bit integer; not a 64-bit integer.