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

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?

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

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

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

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)

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

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.

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)

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?