c#: difference between "System.Object" and "object"

Question

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?

Susurrus

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. – Mackenzie

why don't you post that as an answer? – Susurrus

This is a similar question to this one- #981934 – Come

Answer 1

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

Swallowtail

The remark about language neutrality for public APIs is very interesting indeed! – Susurrus

It's well worth doing this just to shut FxCop up – Dioptric

Language neutrality for public APIs is how much of the .NET libraries work. – Bogeyman

You can usually spot a C# former VB programmer when they use String instead of string (not that it matters). – Come

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. – Come

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 – Clotho

@Clotho I wasn't referring to String. Look at my comment on Jon's answer here if it doesn't make sense- #981934 – Come

@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. – Swallowtail

@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. – Nagle

@MassimilianoKraus: Done. – Swallowtail

Answer 2

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

Lustrous

Answer 3

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

Rozina

Answer 4

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)

Laplante

"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. – Swallowtail

Answer 5

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

Woodpecker

-1 This is incorrect. string and System.String are entirely interchangeable. string is simply an alias for System.String – Likely

This is correct, and I never said they were different. string is a keyword that points at System.String. Perhaps I wasn't clear. – Woodpecker

Actually, I was very clear, "In practise there is no difference..." – Woodpecker

Answer 6

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.

Carat

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. – Swallowtail

(It also uses the word "object" in a pretty fast-and-loose way. It's a generally badly-written article, IMO.) – Swallowtail

Perhaps a better term would be "Keyword Data Types"? – Woodpecker

Or the C# language spec term: aliases. – Swallowtail

Answer 7

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)

Ordzhonikidze

What difference is there between them? – Carat

Try using "String" without a "using System;" directive :) – Swallowtail

@Jon which do you prefer to use? – Nam

@IanC: I usually use the alias. – Swallowtail

Answer 8

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?

Emaciation