Runtime: Language or BCL data types

[patricksadowski]

I'm not sure it's worth to discuss this issue. To ensure consistency within the code base the preferred data types should be noted in the wiki. I know this can be a sensitive and subjective issue...
Only use BCL data types

``` c#
String text;
String.IsNullOrEmpty(text);
Double number;
Double.TryParse(text, out number);

**Only use language data types**

``` c#
string text;
string.IsNullOrEmpty(text);
double number;
double.TryParse(text, out number);

Use language data types for declarations | BCL data types for calling members

c# string text; String.IsNullOrEmpty(text); double number; Double.TryParse(text, out number);

My favorit is the last option because

• an Enum can't inherit from UInt32 so you have to use uint
• because it's not obvious that data types have members
• MSDN says "√ DO use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type."

[sharwell]

Leaving my personal view out of this reply. I just wanted to make a note that the referenced line from MSDN is not related to this particular discussion. It is simply saying this:

// avoid this:
long ToLong();

// use this instead:
long ToInt64();

There is no content on that page describing the use of these types for code which does not form the public API.

[sharwell]

My personal preference is to use only the language data types for type references. I base this on the following reasons:

1. The language-specific keywords are always available, and always presented through IntelliSense, even if using System; has not been included. If I have two ways to reference an item, where one _will_ work and one _might_ work, obviously I would choose the _will_ work method.
2. The default Roslyn diagnostic and code fix for Simplify Type Name converts instances of type references to the language-specific form where possible. No standard diagnostic/code fix is available to migrate to either of the other patterns.
3. It's easier to say "always use this method" instead of "sometimes do this, and sometimes do something else". Conditional coding styles require more evidence to support their inclusion because developers will have to spend more time thinking about their application.

That said, regardless of the coding style used by the project I would always use the conventions of the surrounding code when submitting modifications to an existing file of some project.

[terrajobst]

I second the use of language keywords, as opposed to the type names.

[justinvp]

+1 for language keywords

[weshaggard]

I also prefer language keywords. Before adding this to the coding guidelines I will give some time for other opinions to see if there are any good reasons not to do that.

[mikedn]

+1 for language keywords as well

For the sake of completeness I'll also note 2 objections to this rule that I've seen in the past on forums:

• some prefer to use BCL types for calling static members. As far as I remember the reasoning went something like "language types are keywords and keywords do not have methods". Doesn't seem logical to me, this way you may as well conclude that string is not a type because it is a keyword. But logic has little to do with such preferences. I think there's even a suggestion to make the Roslyn type name simplification optional because of this.
• some prefer the use of BCL integer types (Int32, UInt64 etc.) in places where the type size has particular importance - interop scenarios usually. I think this has some merit but personally I still prefer the language types on the basis that they're nothing more than aliases for BCL types and they are hardcoded in the C# language specification. int is always 32 bits in C#, unlike in C/C++ where its size is compiler dependent.

[Peter-Juhasz]

Use language data types for declarations | BCL data types for calling members
Prefer the last one, because keywords do not have members.

int a = 1; definitely more readable and confortable than Int32 a = 1;
and
Double.Parse("1") is more logical than double.Parse("1")

[mikedn]

There may be other logical reasons to use the BCL types to access members but "because keywords do not have members" isn't one of them.

That's simply a false premise. There is no definition of 'keyword' that claims such a thing, they simply are reserved identifiers without a particular semantic. Depending on the semantics attached by the language, possibly depending on context, keywords may or may not have members. There are other keywords which can be used for member access and they don't even have a non-keyword alternative: true/false, base, this.

And double and string are probably not the best example due the fact that the names differ only by case. float is much more fun:

C# float f; Single.TryParse("42.0", out f);

I find it difficult to justify enforcing such a naming inconsistency via coding guidelines.

[terrajobst]

The "keywords don't have members" reasoning seems somewhat nonsensical to me. When I moved to .NET, my reasoning was that "primitives aren't objects and thus can't have members". Thus, I felt that

int x = 42;
sting s = x.ToString();

was rather strange. However, once you get used to the idea that virtually everything is an object (or can be treated as an object), it's actually rather intuitive.

The way I think of the keywords (and that's probably because I'm a compiler nerd) is that _keywords are simply aliases for the type names_. In that world view, them having members is completely sensible or even obvious. Thus, I honestly don't buy the argument at all.

The interoperatibility argument does hold merit, but given that interop is not common enough I don't think it should trump over the simplicity that keywords offer. I'm fine, however, with a rule that allows using the type names in classes that deal with interop.

[ilmax]

+1 for language keywords

[TommasoScalici]

I also think that going straight with keywords it's clearer and simpler, at least for a C# developer.
I used to write always the keywords/aliases for Base Types, in every context.

[terrajobst]

@weshaggard Do you think we gathered enough feedback? I think we're all siding with keywords.

[weshaggard]

Yes I think we have settled on the guidance of using language keywords. I've updated our coding guidelines wiki to add:

We use language keywords instead of BCL types (i.e. int, string, float instead of Int32, String, Single, etc) for both type references as well as method calls (i.e. int.Parse instead of Int32.Parse). See issue 391 for examples.

Thanks everyone for the discussion I'm closing this issue now.

[DavidYamer]

+1 for language keywords