Example (note the case):
string s = \"Hello world!\";
String s = \"Hello world!\";
What are
Just for the sake of completeness, here's a brain dump of related information...
As others have noted, string
is an alias for System.String
. Assuming your code using String
compiles to System.String
(i.e. you haven't got a using directive for some other namespace with a different String
type), they compile to the same code, so at execution time there is no difference whatsoever. This is just one of the aliases in C#. The complete list is:
object: System.Object
string: System.String
bool: System.Boolean
byte: System.Byte
sbyte: System.SByte
short: System.Int16
ushort: System.UInt16
int: System.Int32
uint: System.UInt32
long: System.Int64
ulong: System.UInt64
float: System.Single
double: System.Double
decimal: System.Decimal
char: System.Char
Apart from string
and object
, the aliases are all to value types. decimal
is a value type, but not a primitive type in the CLR. The only primitive type which doesn't have an alias is System.IntPtr
.
In the spec, the value type aliases are known as "simple types". Literals can be used for constant values of every simple type; no other value types have literal forms available. (Compare this with VB, which allows DateTime
literals, and has an alias for it too.)
There is one circumstance in which you have to use the aliases: when explicitly specifying an enum's underlying type. For instance:
public enum Foo : UInt32 {} // Invalid
public enum Bar : uint {} // Valid
That's just a matter of the way the spec defines enum declarations - the part after the colon has to be the integral-type production, which is one token of sbyte
, byte
, short
, ushort
, int
, uint
, long
, ulong
, char
... as opposed to a type production as used by variable declarations for example. It doesn't indicate any other difference.
Finally, when it comes to which to use: personally I use the aliases everywhere for the implementation, but the CLR type for any APIs. It really doesn't matter too much which you use in terms of implementation - consistency among your team is nice, but no-one else is going to care. On the other hand, it's genuinely important that if you refer to a type in an API, you do so in a language-neutral way. A method called ReadInt32
is unambiguous, whereas a method called ReadInt
requires interpretation. The caller could be using a language that defines an int
alias for Int16
, for example. The .NET framework designers have followed this pattern, good examples being in the BitConverter
, BinaryReader
and Convert
classes.
string
is a reserved word, but String
is just a class name.
This means that string
cannot be used as a variable name by itself.
If for some reason you wanted a variable called string, you'd see only the first of these compiles:
StringBuilder String = new StringBuilder(); // compiles
StringBuilder string = new StringBuilder(); // doesn't compile
If you really want a variable name called string you can use @
as a prefix:
StringBuilder @string = new StringBuilder();
Another critical difference: Stack Overflow highlights them differently.
As the others are saying, they're the same. StyleCop rules, by default, will enforce you to use string
as a C# code style best practice, except when referencing System.String
static functions, such as String.Format
, String.Join
, String.Concat
, etc...
String
is not a keyword and it can be used as Identifier whereas string
is a keyword and cannot be used as Identifier. And in function point of view both are same.
It's a matter of convention, really. string
just looks more like C/C++ style. The general convention is to use whatever shortcuts your chosen language has provided (int/Int for Int32
). This goes for "object" and decimal
as well.
Theoretically this could help to port code into some future 64-bit standard in which "int" might mean Int64
, but that's not the point, and I would expect any upgrade wizard to change any int
references to Int32
anyway just to be safe.
String
stands for System.String
and it is a .NET Framework type. string
is an alias in the C# language for System.String
. Both of them are compiled to System.String
in IL (Intermediate Language), so there is no difference. Choose what you like and use that. If you code in C#, I'd prefer string
as it's a C# type alias and well-known by C# programmers.
I can say the same about (int
, System.Int32
) etc..