New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language or BCL data types #391

Closed
patricksadowski opened this Issue Jan 10, 2015 · 14 comments

Comments

Projects
None yet
@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

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

Only use language data types

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

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

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

This comment has been minimized.

Show comment
Hide comment
@sharwell

sharwell Jan 10, 2015

Member

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.

Member

sharwell commented Jan 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sharwell

sharwell Jan 10, 2015

Member

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.

Member

sharwell commented Jan 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Jan 10, 2015

Member

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

Member

terrajobst commented Jan 10, 2015

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

@justinvp

This comment has been minimized.

Show comment
Hide comment
@justinvp

justinvp Jan 11, 2015

Collaborator

+1 for language keywords

Collaborator

justinvp commented Jan 11, 2015

+1 for language keywords

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 11, 2015

Member

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.

Member

weshaggard commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikedn

mikedn Jan 11, 2015

Collaborator

+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.
Collaborator

mikedn commented Jan 11, 2015

+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

This comment has been minimized.

Show comment
Hide comment
@Peter-Juhasz

Peter-Juhasz Jan 11, 2015

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")

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

This comment has been minimized.

Show comment
Hide comment
@mikedn

mikedn Jan 11, 2015

Collaborator

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:

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

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

Collaborator

mikedn commented Jan 11, 2015

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:

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

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

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Jan 11, 2015

Member

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.

Member

terrajobst commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ilmax

ilmax Jan 12, 2015

+1 for language keywords

ilmax commented Jan 12, 2015

+1 for language keywords

@TommasoScalici

This comment has been minimized.

Show comment
Hide comment
@TommasoScalici

TommasoScalici Jan 13, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Jan 13, 2015

Member

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

Member

terrajobst commented Jan 13, 2015

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

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 13, 2015

Member

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.

Member

weshaggard commented Jan 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@DavidYamer

DavidYamer Jul 29, 2016

+1 for language keywords

+1 for language keywords

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment