74

In C#, is there any difference between using System.Object in code rather than just object, or System.String rather than string and so on? Or is it just a matter of style?

Is there a reason why one form is preferrable to the other?

Paolo Tedesco
  • 55,237
  • 33
  • 144
  • 193
  • 5
    Here's how I do it: I use int or string in the context of a primitive variable (such as int x = 0) and use Int32 and String etc in the context of classes (such as Int32.Parse or String.Empty) - doesn't make any difference though, in the end it gets compiled to the same CLR type. – Tamas Czinege Jun 19 '09 at 10:33
  • 2
    why don't you post that as an answer? – Paolo Tedesco Jun 19 '09 at 10:38
  • 1
    This is a similar question to this one- http://stackoverflow.com/questions/981434/can-anyone-give-me-a-really-good-reason-to-use-clr-type-names-instead-of-c-type – RichardOD Jun 19 '09 at 11:39

8 Answers8

72

string is an alias for global::System.String. It's simply syntactic sugar. The two are exactly interchangable in almost all cases, and there'll be no difference in the compiled code.

Personally I use the aliases for variable names etc, but I use the CLR type names for names in APIs, for example:

public int ReadInt32() // Good, language-neutral

public int ReadInt() // Bad, assumes C# meaning of "int"

(Note that the return type isn't really a name - it's encoded as a type in the metadata, so there's no confusion there.)

The only places I know of where one can be used and the other can't (that I'm aware of) are:

  • nameof prohibits the use of aliases
  • When specifying an enum base underlying type, only the aliases can be used
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 10
    The remark about language neutrality for public APIs is very interesting indeed! – Paolo Tedesco Jun 19 '09 at 10:31
  • 3
    It's well worth doing this just to shut FxCop up – Patrick McDonald Jun 19 '09 at 11:00
  • 1
    Language neutrality for public APIs is how much of the .NET libraries work. – yfeldblum Jun 19 '09 at 11:21
  • You can usually spot a C# former VB programmer when they use String instead of string (not that it matters). – RichardOD Jun 19 '09 at 11:23
  • I'm sure this is mentioned in another question, but I'll mention it for completeness. In CLR via C#, Jeffrey Ritcher recommends you always use the language neutral type names everywhere. However the defacto standard is as Jon describes. – RichardOD Jun 19 '09 at 11:27
  • This does not make sense. What language neutrality are we talking about. Whether it is a public API or not when compiled no one can tell if you used string or String – Stilgar Jun 19 '09 at 11:33
  • 1
    @Stilgar I wasn't referring to String. Look at my comment on Jon's answer here if it doesn't make sense- http://stackoverflow.com/questions/981434/can-anyone-give-me-a-really-good-reason-to-use-clr-type-names-instead-of-c-type – RichardOD Jun 19 '09 at 11:37
  • 2
    @Stilgar: That's why my answer used int/Int32 rather than string/String. Yes, it doesn't matter for String/Object/Decimal/Double/Byte/SByte - but it does matter for all the rest. – Jon Skeet Jun 19 '09 at 13:14
  • @JonSkeet maybe it's worth updating your answer with the `nameof` issue, which allows `Object`, `String`, etc, but NOT their C# synonimous like `object`, `string`, etc. – Massimiliano Kraus May 29 '17 at 22:13
  • @MassimilianoKraus: Done. – Jon Skeet May 30 '17 at 07:01
9

The object type is an alias for System.Object. The object type is used and shown as a keyword. I think it has something to do with legacy, but that's just a wild guess.

Have a look at this MSDN page for all details.

I prefer the use of the lowercased versions, but for no special reasons. Just because the syntax highlighting is different on these "basic" types and I don't have to use the shift key when typing...

Sorskoot
  • 10,190
  • 6
  • 55
  • 98
6

One is an alias to the other. Its down to style.

Johnno Nolan
  • 29,228
  • 19
  • 111
  • 160
3

string is an alias for global::System.String, and object for global::System.Object

Providing you have using System; in your class, String / string and Object / object are functionally identical and usage is a matter of style.

(EDIT: removed slightly misleading quote, as per Jon Skeet's comment)

Colin Pickard
  • 45,724
  • 13
  • 98
  • 148
  • 3
    "String" with a capital letter doesn't have any meaning to the C# compiler or the C# language. "string" *always* corresponds to global::System.String. I don't know where the original author gets the notion that "String" has special meaning. – Jon Skeet Jun 19 '09 at 10:26
1

string (with the lowercase "s") is the string type of the C# language and the type System.String is the implementation of string in the .NET framework.

In practise there is no difference besides stylistic ones.

EDIT: Since the above obviously wasn't clear enough, there is no difference between them, they are the same type once compiled. I was explaining the semantic difference that the compiler sees (which is just syntactic sugar, much like the difference between a while and for loop).

Matthew Scharley
  • 127,823
  • 52
  • 194
  • 222
0

There are no difference. There is a number of types, called Primitive Data Types which are threated by compiler in style you mentioned.

Capitalized naming style is ISO naming rule. It's more general, common; forces the same naming rules for all objects in the source without exceptions such C# compiler has.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
  • 1
    That article is poorly written to use the word "primitive" there. If you look at the docs for Type.IsPrimitive you'll see: "The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Double, and Single." Note that this *doesn't* include string, decimal and object, but *does* include IntPtr and UIntPtr. – Jon Skeet Jun 19 '09 at 10:23
  • 1
    (It also uses the word "object" in a pretty fast-and-loose way. It's a generally badly-written article, IMO.) – Jon Skeet Jun 19 '09 at 10:24
  • Perhaps a better term would be "Keyword Data Types"? – Matthew Scharley Jun 19 '09 at 10:26
  • 1
    Or the C# language spec term: aliases. – Jon Skeet Jun 19 '09 at 10:31
0

As of my knowledge, I know that it's a shortcut, it's easier to use string, rather than System.string.

But be careful there's a difference between String and string (c# is case sensitive)

Omar Abid
  • 15,753
  • 28
  • 77
  • 108
0

object, int, long and bool were provided as training wheels for engineers that had trouble adapting to the idea that the data types were not a fixed part of the language. C#, unlike the languages that went before it, has no limit on the number of data types you can add. The 'System' library provides a starter kit featuring such useful types as System.Int32, System.Boolean, System.Double, System.DateTime and so on, but engineers are encouraged to add their own. Because Microsoft was interested in quick adoption of their new language, they provided aliases that made it appear as if the language was more 'C'-like, but these aliases are a completely disposable feature (C# would be just as good a language if you removed all the build-in aliases, probably better).

While StyleCop does enforce the use of the legacy C-style aliases, it is a blemish on an otherwise logical set of rules. As of yet, I've not heard a single justification for this rule (SA1121) that wasn't based on dogma. If you think SA1121 is logical, then why is there no buildin type for datetime?

Quark Soup
  • 4,272
  • 3
  • 42
  • 74