Multi tool use

What is the difference between String and string in C#?

Example (note the case):

string s = "Hello world!";
String s = "Hello world!";


What are the guidelines for the use of each? And what are the differences?

string

System.String

string

string

System.String

string

String

string

System.String

string

string.Format()

System.String

57 Answers
57

string is an alias in C# for System.String.
So technically, there is no difference. It's like int vs. System.Int32.

string

System.String

int

System.Int32

As far as guidelines, it's generally recommended to use string any time you're referring to an object.

string

e.g.

string place = "world";


Likewise, I think it's generally recommended to use String if you need to refer specifically to the class.

String

e.g.

string greet = String.Format("Hello {0}!", place);


This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

string.Format()

nameof(string)

nameof(String)

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

string

System.String

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.

string

object

decimal

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

DateTime

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.

sbyte

byte

short

ushort

int

uint

long

ulong

char

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

ReadInt32

ReadInt

int

Int16

BitConverter

BinaryReader

Convert

string

String

string' is a keyword in c#, so you can not use it as a variable name.For Ex:

//compiler error, but

String

@string

string

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.

String

System.String

string

System.String

System.String

string

I can say the same about (int, System.Int32) etc..

int

System.Int32

The best answer I have ever heard about using the provided type aliases in C# comes from Jeffrey Richter in his book CLR Via C#. Here are his 3 reasons:

BinaryReader br = new BinaryReader(...);
float val = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good


So there you have it. I think these are all really good points. I however, don't find myself using Jeffrey's advice in my own code. Maybe I am too stuck in my C# world but I end up trying to make my code look like the framework code.

string

int

long

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.

string

String

string

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.

@string

_string

@string

"string"

There is one difference - you can't use String without using System; beforehand.

String

using System;

using

internal sealed

It's been covered above; however, you can't use string in reflection; you must use String.

string

String

System.String is the .NET string class - in C# string is an alias for System.String - so in use they are the same.

System.String

string

System.String

As for guidelines I wouldn't get too bogged down and just use whichever you feel like - there are more important things in life and the code is going to be the same anyway.

If you find yourselves building systems where it is necessary to specify the size of the integers you are using and so tend to use Int16, Int32, UInt16, UInt32 etc. then it might look more natural to use String - and when moving around between different .net languages it might make things more understandable - otherwise I would use string and int.

Int16

Int32

UInt16

UInt32

String

I prefer the capitalized .NET types (rather than the aliases) for formatting reasons. The .NET types are colored the same as other object types (the value types are proper objects, after all).

.NET

.NET

Conditional and control keywords (like if, switch, and return) are lowercase and colored dark blue (by default). And I would rather not have the disagreement in use and format.

if

switch

return

Consider:

String someString;
string anotherString;


Int32 i=1;

int i = 1;

var

string and String are identical in all ways (except the uppercase "S"). There are no performance implications either way.

string

String

Lowercase string is preferred in most projects due to the syntax highlighting

string

C# is a language which is used together with the CLR.

string is a type in C#.

string

System.String is a type in the CLR.

System.String

When you use C# together with the CLR string will be mapped to System.String.

string

System.String

Theoretically, you could implement a C#-compiler that generated Java bytecode. A sensible implementation of this compiler would probably map string to java.lang.String in order to interoperate with the Java runtime library.

string

java.lang.String

string

This YouTube video demonstrates practically how they differ.

But now for a long textual answer.

When we talk about .NET there are two different things one there is .NET framework and the other there are languages ( C# , VB.NET etc) which use that framework.

.NET

.NET

C#

VB.NET

"System.String" a.k.a "String" ( capital "S") is a .NET framework data type while "string" is a C# data type.

System.String

.NET

C#

In short "String" is an alias ( the same thing called with different names) of "string". So technically both the below code statements will give the same output.

String s = "I am String";


or

string s = "I am String";


In the same way there are aliases for other c# data type as shown below:-

object: System.Object, string: System.String, bool: System.Boolean, byte: System.Byte, sbyte: System.SByte, short: System.Int16 and so on

System.Object

System.String

System.Boolean

System.Byte

System.SByte

System.Int16

Now the million dollar question from programmer's point of view So when to use "String" and "string"?

First thing to avoid confusion use one of them consistently. But from best practices perspective when you do variable declaration it's good to use "string" ( small "s") and when you are using it as a class name then "String" ( capital "S") is preferred.

In the below code the left hand side is a variable declaration and it declared using "string". At the right hand side we are calling a method so "String" is more sensible.

string s = String.ToUpper() ;


String

string

string is just an alias for System.String. The compiler will treat them identically.

string

System.String

The only practical difference is the syntax highlighting as you mention, and that you have to write using System if you use String.

using System

String

using System

String

The type or namespace name 'String' could not be found (are you missing a using directive or an assembly reference?)

Lower case string is an alias for System.String.
They are the same in C#.

string

System.String

C#

There's a debate over whether you should use the System types (System.Int32, System.String, etc.) types or the C# aliases (int, string, etc). I personally believe you should use the C# aliases, but that's just my personal preference.

System.Int32

System.String

C# aliases

int

string

C# aliases

Both are same. But from coding guidelines perspective it's better to use string instead of String. This is what generally developers use. e.g. instead of using Int32 we use int as int is alias to Int32

string

String

Int32

int

int

Int32

FYI
“The keyword string is simply an alias for the predefined class System.String.” - C# Language Specification 4.2.3
http://msdn2.microsoft.com/En-US/library/aa691153.aspx

System.String

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

System.String

String.Format

String.Join

String.Concat

Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.

Against what seems to be common practice among other programmers, I prefer String over string, just to highlight the fact that String is a reference type, as Jon Skeet mentioned.

String

string

String

string is an alias (or shorthand) of System.String. That means, by typing string we meant System.String. You can read more in think link: 'string' is an alias/shorthand of System.String.

string

System.String

string

System.String

String (System.String) is a class in the base class library. string (lower case) is a reserved work in C# that is an alias for System.String. Int32 vs int is a similar situation as is Boolean vs. bool. These C# language specific keywords enable you to declare primitives in a style similar to C.

System.String

Boolean vs. bool

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.

String

string

Coming late to the party: I use the CLR types 100% of the time (well, except if forced to use the C# type, but I don't remember when the last time that was).

I originally started doing this years ago, as per the CLR books by Ritchie. It made sense to me that all CLR languages ultimately have to be able to support the set of CLR types, so using the CLR types yourself provided clearer, and possibly more "reusable" code.

Now that I've been doing it for years, it's a habit and I like the coloration that VS shows for the CLR types.

The only real downer is that auto-complete uses the C# type, so I end up re-typing automatically generated types to specify the CLR type instead.

Also, now, when I see "int" or "string", it just looks really wrong to me, like I'm looking at 1970's C code.

I'd just like to add this to lfousts answer, from Ritchers book:

The C# language specification states,
“As a matter of style, use of the
keyword is favored over use of the
complete system type name.” I disagree
with the language specification; I
prefer to use the FCL type names and
completely avoid the primitive type
names. In fact, I wish that compilers
didn’t even offer the primitive type
names and forced developers to use the
FCL type names instead. Here are my
reasons:

I didn't get his opinion before I read the complete paragraph.

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.

There is no difference.

The C# keyword string maps to the .NET type System.String - it is an alias that keeps to the naming conventions of the language.

string

System.String

Similarly, int maps to System.Int32.

int

System.Int32

int*

New answer after 6 years and 5 months (procrastination).

While string is a reserved C# keyword that always has a fixed meaning, String is just an ordinary identifier which could refer to anything. Depending on members of the current type, the current namespace and the applied using directives and their placement, String could be a value or a type distinct from global::System.String.

string

String

using

String

global::System.String

I shall provide two examples where using directives will not help.

using

First, when String is a value of the current type (or a local variable):

String

class MySequence<TElement>
{
public IEnumerable<TElement> String { get; set; }

void Example()
{
var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
}
}


The above will not compile because IEnumerable<> does not have a non-static member called Format, and no extension methods apply. In the above case, it may still be possible to use String in other contexts where a type is the only possibility syntactically. For example String local = "Hi mum!"; could be OK (depending on namespace and using directives).

IEnumerable<>

Format

String

String local = "Hi mum!";

using

Worse: Saying String.Concat(someSequence) will likely (depending on usings) go to the Linq extension method Enumerable.Concat. It will not go to the static method string.Concat.

String.Concat(someSequence)

using

Enumerable.Concat

string.Concat

Secondly, when String is another type, nested inside the current type:

String

class MyPiano
{
protected class String
{
}

void Example()
{
var test1 = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
String test2 = "Goodbye";
}
}


Neither statement in the Example method compiles. Here String is always a piano string, MyPiano.String. No member (static or not) Format exists on it (or is inherited from its base class). And the value "Goodbye" cannot be converted into it.

Example

String

MyPiano.String

static

Format

"Goodbye"

using String = System.Int32; using Int32 = System.String;

string is a keyword, and you can't use string as an identifier.

String is not a keyword, and you can use it as an identifier:

Example

string String = "I am a string";


The keyword string is an alias for
System.String aside from the keyword issue, the two are exactly
equivalent.

string

System.String

typeof(string) == typeof(String) == typeof(System.String)


There's a quote on this issue from Daniel Solis' book.

All the predefined types are mapped directly to
underlying .NET types. The C# type names (string) are simply aliases for the
.NET types (String or System.String), so using the .NET names works fine syntactically, although
this is discouraged. Within a C# program, you should use the C# names
rather than the .NET names.

Yes, that's no difference between them, just like the bool and Boolean.

bool

Boolean

There is no difference between the two - string, however, appears to be the preferred option when considering other developers' source code.

string

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).


Would you like to answer one of these unanswered questions instead?