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

5 605

869

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?

Lance Fisher

Posted 2008-08-10T07:18:02.320

Reputation: 16 588

39@O.R.Mapper, but the fact remains that string is a lexical construct of the C# grammar whereas System.String is just a type. Regardless of any explicit difference mentioned in any spec, there is still this implicit difference that could be accomodated with some ambiguity. The language itself must support string in a way that the implementation is not (quite) so obligated to consider for a particular class in the BCL. – Kirk Woll – 2014-12-02T03:05:22.927

68@KirkWoll: According to the language specification, the language itself must consider string to be exactly the same as the BCL type System.String, nothing else. That is not ambiguous at all. Of course, you can implement your own compiler, using the C# grammar, and use all of the tokens found like that for something arbitrary, unrelated to what is defined in the C# language specification. However, the resulting language would only be a C# lookalike, it could not be considered C#. – O. R. Mapper – 2014-12-02T08:22:33.823

47You can use string without a using directive for System. You can't do that with String. – Wilsu – 2015-11-30T08:52:40.313

read about Boxing/Unboxing too btw. - https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx - "The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object"

– George Birbilis – 2016-05-10T17:39:05.837

string is an alias in C#. while String belongs to System.String There is no such difference in both. – Khuram Nawaz – 2016-06-17T11:03:55.767

6For someone coming from Algol and Fortran, this discussion shows there is something wrong with string. It is needed to abbreviate System.String, but, as an alias, it seems quite like, but not exactly the same thing. After several years of C#, though, I'd say, it is safe to simply use string and string.Format() and not to worry about System.String. – Roland – 2016-12-20T00:24:25.127

Technically there is no difference – Kanisq – 2017-03-05T15:35:43.977

67If this kind of question were asked in 2017, it would've received 4,000 downvotes, 2,000 links to the MSDN String class page, and closed as not productive. – IRGeekSauce – 2017-12-04T07:12:15.050

6IRGeekSauce, But of course, questions like these have become very popular, and the majority of SO users have become tired to answer these already. But in the early times, not many knew about these questions, and so they grow more curious about. The question now may not show research effort, but it's clear and useful. Several answers on StackOverflow explain it more simple and clear than MSDN would. – Steven – 2018-04-12T12:32:33.833

3@IRGeekSauce Yeah, I get what you're saying... And the bit that you're too polite to say is that an MSDN page will tell you what to do, with some frustrating gaps of implied knowledge in their instructions of how to do it; and all the interesting information about why and "how it bites you if you didn't know" is here on Stack Overflow. – Nigel Heffernan – 2018-04-26T11:21:39.390

4@IRGeekSauce Man you're my soulmate. Just note that in 2018, it would receive about 4 downvotes and 2 doc links because it would be closed within 30 seconds by high rep users saying this question is so obvious, even though it brought near 1 million views until today... So ironic, because these questions are one of the main reason StackOverflow actually exists. I'll just go and give a super satisfying +1. – scharette – 2018-06-06T19:36:27.437

Since 2014 conventions have changed a lot in .net framework. Now there's no existence for String (capital s) while declaring variables. only alias string (small s) is available. Microsoft might wanted to remove confusing programming approach! – Sangeeta – 2018-11-29T09:53:06.533

Answers

5 312

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

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

e.g.

string place = "world";

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

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.

Derek Park

Posted 2008-08-10T07:18:02.320

Reputation: 39 219

4

@JonSkeet - Like you, I prefer the aliased types. The Design Guidelines for Developing Class Libraries - General Naming Conventions recommends developers stick to the language specific naming, rather than the CLR type. They do so in the Convert methods, to save them re-defining it for every language.

– Dominic Zukiewicz – 2012-04-20T11:52:21.477

5@Dominic: That's in member names though, not implementation. I'm fine with (say) public int ReadInt32(). – Jon Skeet – 2012-04-20T12:24:48.467

123

If you decide to use StyleCop and follow that, that will say to use the types specific to the language. So for C# you'll have string (instead of String), int (instead of Int32), float (instead of Single) - http://stylecop.soyuz5.com/SA1121.html

– Dominic Zukiewicz – 2012-05-22T22:36:15.657

93I always use the aliases because I've assumed one day it might come in handy because they are acting as an abstraction, so therefore can have their implementations changed without me having to know. – Rob – 2012-10-12T23:25:39.303

4Isn't the second example "`string greet = String.Format("Hello {0}!", place);" meant to have a capital S? String? – JARRRRG – 2014-05-12T23:04:24.607

2One of the major advantage of String.Format that I have actually seen in real source code is when it's used this way, String.Format("The value of a is {0}", a); a being any variable declared and initialized. This way of formatting the strings have various advantages. One very simple example would be when say variable a is a value of a currency we can have £ or $ or whichever currency symbol formatted into the string. – Abhi – 2014-12-15T17:46:22.857

18Visual Studio 2015 says that String.Format should be changed to string.Format, so I guess Microsoft is going that way. I have also always used String for the static methods. – Sami Kuhmonen – 2014-12-22T05:21:27.913

1To add to the conversation I noticed that if you declare an object using String and not string, calling methods like Equals("text") or StartsWith("text") do not work and always return false. – Klitos G. – 2015-03-15T12:47:19.743

19As I've read through these I've notice several of the comments are simply incorrect. @DRAirey1 In time, you'll find that the old way is still the best, if you doubt that then I dare you to try to write C# code without using Visual Studio. It's virtually impossible and a situation that does come up from time to time in web development work. @Vlad You don't need to import anything to use String. @Abhi Your comment is pointless and equally true for string.Format(). @KlitosG No, that isn't true. They all work exactly the same. – krowe2 – 2015-05-29T14:30:54.330

3I don't like the aliases. The class name feels logical to use (e.g. String.Format()), is generally more descriptive (e.g. Int32 vs int), and is immediately clear where it fits in the framework (within System). But it looks like MS wants us to use the aliases, so that's what we'll have to do. – Zesty – 2015-07-23T07:09:32.207

1

as a note to prevent confusion: Some c# to vb.net converter convert String(c#) to String and string(c#) to string(vb).

– ruedi – 2015-08-24T10:08:49.140

1I prefer the lowercase as the syntax color is different from classes and it gives me a feeling of using the builtin language features over something implemented. – Waters – 2015-08-25T13:24:36.773

1I always use the string alias, especially if I can avoid the "using System" statement. #lovesNegativeLinesOfCode – David Pine – 2015-11-21T05:08:48.237

22Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will. – Jeroen Vannevel – 2016-02-05T20:38:26.517

1java needs these aliases, it gets angry when I use 'string' instead of 'String'. C# doesn't care. – Broken_Window – 2016-02-19T15:33:54.993

4Sorry for the dumb question, but any idea of why do we need such alias? – Żubrówka – 2016-03-04T13:19:31.257

4Visual Studio 2015 suggest string.Format – Razzer – 2016-03-16T12:46:45.100

@krowe2 In C# you have to include a using System; directive before you can refer to String in a class. Perhaps you're thinking of VB which does not seem to require an equivalent Imports directive. – beercohol – 2016-05-04T15:41:14.157

Not exacly an alias as string is a global struct, not a class, that happens to be a wrapper around the System.String type. – SparK – 2016-06-02T12:53:20.840

string should be used everywhere instead of String – Vahid Amiri – 2016-06-12T12:31:28.670

So everyone here is suggesting to do this? new string('-', 100) Ugh! I prefer to use BCL names when accessing static members such as Int32.Parse or when calling the constructor. Use aliases when you are specifying a type. – orad – 2016-08-04T23:04:05.247

@MikaelPuusaari: "If you reference Int16 instead of int, you will specify the type from the default Int32." - it is rather unclear what you are trying to say there (and actually, in that complete paragraph). Could you try to rephrase and/or provide a concrete example of what you mean (that illustrates how int vs. Int32 is different from string vs. String)? – O. R. Mapper – 2017-01-12T12:57:59.403

1I used to prefer the syntax String.Format(), but the latest version of Visual Studio actually flags that as an expression that can be simplified. And when you simplify it, it just becomes string.Format(). So, as far as Visual Studio is concerned, string is always the preferred syntax when working with C#. – Jonathan Wood – 2017-02-22T17:28:03.083

2@SparK No, string is not a struct; it refers always to the class System.String. They are 100% identical in the IL. – Andy – 2018-03-15T16:25:45.720

Also, for type parameters with generics, MSDN examples favour List<string> over List<String> – Max Barraclough – 2018-05-22T14:18:21.773

3The key difference is string is guaranteed to always refer to System.String, whereas String could refer to a different class with the same name in a different namespace – userSteve – 2018-07-09T10:54:21.003

1@userSteve I have just been hit with that issue last August and it took a while to figure out it was the wrong namespace. – Franck – 2018-10-03T14:27:27.417

@Rob: I don't see your point. If string had its implementation changed in such a way that your program's behavior was changed, would you not like to know? If, however, the changes are such that your (and everyone else's) programs won't change behavior, why would String not have its implementation changed instead of string? Your additional layer of abtraction would only be of use if you were the one to control it, e.g. if you defined RobString to point to String for now, and maybe to something else of your liking at a later point in time. (Not that I necessarily recommend this.) – RQM – 2018-10-05T15:46:37.677

3 133

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:

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

Jon Skeet

Posted 2008-08-10T07:18:02.320

Reputation: 1 070 456

1+1 for mentioning the enum situation. That's the real answer I would consider it to be. The enum in c# are not considered to be the integer(int) values like in c++. So you should either typecast it or convert it at declaration like @JonSkeet has mentioned it. Should you do this, then it has to be considered a 'type' . The keywords are alone considered which is in our case, a set of aliases of the original classes. – King – 2011-12-26T19:41:17.073

5Your comment: "It doesn't explicitly say that you've got to use the alias, but the aliases are sort of treated as their own types. It's all a bit weird." – phoog – 2011-12-29T19:53:52.683

3@phoog: Ah, sorry, I didn't realise you were referring to a comment. Yes, it's well-specified, I agree. – Jon Skeet – 2011-12-29T19:56:53.753

6@pinusnegra: No, it's not - at least not in the same way as the others. You can't declare a method as returning System.Void for example. You can't use System.Void directly in C# like that. – Jon Skeet – 2012-01-09T23:18:19.307

6@JonSkeet ahh, right :) I didn't check, just wondered, because I thought it's a keyword. Then what's the point of System.Void? – Peter Porfy – 2012-01-09T23:34:53.820

1@JonSkeet "decimal is a value type, but not a primitive type in the CLR" can you please explain this idea more? – Hussein Zawawi – 2012-03-29T15:47:19.137

4@HusseinX: Sure - look in the CLI spec and you'll see that there are no instructions for dealing with decimal. It's "just another value type" as far as the CLR is concerned. – Jon Skeet – 2012-03-29T16:12:31.570

28One interesting difference between string and String is that string' is a keyword in c#, so you can not use it as a variable name.For Ex:string string="hi";//compiler error, butString String="hi";is acceptable, asString` is an identifire not a keyword. – Sanjeev Rai – 2013-06-05T07:09:27.180

27@SanjeevRai: Yes. You can use @string to create an identifier which ends up as string though. It's a sort of escaping mechanism. – Jon Skeet – 2013-06-05T07:18:18.850

7

@PeterPorfy System.Void is used in reflection when inspecting methods without return values, for example in MethodInfo.ReturnParameter.

– Niels Keurentjes – 2013-07-30T10:04:08.613

2@NielsKeurentjes I got closer to the concept of void since by learning about the unit type of F#. Reflection also makes sense, thank you! – Peter Porfy – 2013-07-30T10:50:32.830

4"the aliases are all to value types" is said twice about different sets of aliases. Can't be true both times %) – Max Galkin – 2010-05-11T17:08:40.330

3When you do f12 on string or String it goes to the same String class metadata file. – sandeep talabathula – 2014-01-18T05:00:45.700

6Thanks for the great explanation @JonSkeet! On a lighter note, I had a colleague a couple of years ago who preferred to use System.String because he liked the aqua colour that visual studio gives it better than the darker blue of 'string'! – Adam Diament – 2015-05-10T20:13:10.343

OK, but what makes people write String instead of string? Many open source code with String. Hm. – GRUNGER – 2015-09-04T17:10:40.197

1@AdamDiment they should use ReSharper, this will make the fancy aqua fade out a bit because it says to use string instead of String ;) – Mafii – 2016-06-02T07:43:44.903

2

@JonSkeet It appears that the enums-must-use-alias requirement has been lifted either in C# 6 or some time before it (related question).

– dasblinkenlight – 2016-06-02T10:26:59.507

isn't uint a wrapper struct (like enum, around a class) and UInt32 a wrapper class (around a primitive)? – SparK – 2016-06-02T12:56:28.153

2@SparK: No, not at all. And enums aren't wrappers around classes either. uint is only an alias for UInt32. They're exactly the same type, both structs (not classes). – Jon Skeet – 2016-06-02T13:40:43.333

70The inheritance situation with enum is interesting. Can you point to documentation onto why alias must be used for enumerations? Or is this a known bug? – JaredPar – 2008-10-19T02:00:57.717

127It's in section 14.1 of the spec (I can't quote here easily as it's too long). It doesn't explicitly say that you've got to use the alias, but the aliases are sort of treated as their own types. It's all a bit weird. – Jon Skeet – 2008-10-19T06:34:02.377

27@PiPeep what's more astounding than the large amount of upvotes is the staggering low amount of downvotes (consider the top 5 posts have a total of over 2000 upvotes, and yet only 1 downvote amongst them all). Especially when you factor in the notion that there's always "haters" in any community, I really find that simply incredible. – corsiKa – 2011-09-09T21:27:44.347

630

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

artur02

Posted 2008-08-10T07:18:02.320

Reputation: 4 121

1If you code in C#, I'd prefer string as it's a C# type alias and well-known by C# programmers - when would a C# person not know the .NET framework. +1 as I think generally this is the best answer, but the point I mention seems odd. – MyDaftQuestions – 2015-11-16T08:31:12.150

I personally prefer using "Int32", since it immediately shows the range of the value. Imagine if they upgraded the type of "int" on later higher-bit systems. 'int' in c is apparently seen as "the integer type that the target processor is most efficient working with", and defined as "at least 16 bit". I'd prefer predictable consistency there, thank you very much. – Nyerguds – 2016-04-28T11:41:38.627

@MyDaftQuestions I concur. If anything it would make sense to consistently use the .net types because they are language ignorant and the type is obvious, independent of any language (do I know all of F#'s or VB's idiosyncrasies?). – Peter A. Schneider – 2017-01-21T17:39:59.213

437

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:

  • I've seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# the string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used.
  • In C#, long maps to System.Int64, but in a different programming language, long could map to an Int16 or Int32. In fact, C++/CLI does in fact treat long as an Int32. Someone reading source code in one language could easily misinterpret the code's intention if he or she were used to programming in a different programming language. In fact, most languages won't even treat long as a keyword and won't compile code that uses it.
  • The FCL has many methods that have type names as part of their method names. For example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32, ReadSingle, and so on, and the System.Convert type offers methods such as ToBoolean, ToInt32, ToSingle, and so on. Although it's legal to write the following code, the line with float feels very unnatural to me, and it's not obvious that the line is correct:
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.

Luke Foust

Posted 2008-08-10T07:18:02.320

Reputation: 1 741

14The second point sounds actually like a reason not to use string, int etc. – MauganRa – 2015-06-15T15:37:29.797

11@MauganRa And it's supposed to, the author of the book lists those reasons as to why he doesn't use aliases. – tomi.lee.jones – 2015-09-15T17:48:00.697

24"If someone is reading C# source code they should interpret long according to the language spec, not another languages spec." That misses the point entirely. It's not that anyone intends to misinterpret code, it's simply easy for one's brain to jump to the wrong conclusion when a type has a different meaning than what the programmer sees on a daily basis in another context. We all make mistakes; using explicitly named types makes those mistakes less likely. – Darryl – 2015-09-21T22:11:04.330

1

@Darryl - I remember programming with .NET 1.x on Windows XP 32x. One of the kernel APIs required a long, and I kept getting overflow errors by using a .NET long for the struct I was passing in; it had to be a .NET int /Int32 to translate to the kernel's definition of a long. So there's still room for confusion! https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

– ps2goat – 2016-08-31T04:15:22.520

9+These reasons sum up my feelings on the matter. When I first started coding in C# (coming from a Java/C++/C background) I thought the aliases were ugly. I still feel that way, unfortunately most of the world doesn't seem to agree with me, or they don't care, and so use the lowercase. – gusgorman – 2017-03-02T10:41:21.053

2The "bittedness" of an integer is reliant upon the compiler, not the language. The reason you get overflows using "long" is not because of the kernel, it is because of the compiler. Microsoft 16 bit compilers used a 16 bit integer size, 32 bit compilers used a 32 bit integer size. "string": is actually an "alias" for char*, but that is all out the window with .NET -- which is why IntPtr has no primitive equivalent -- no pointers. – jinzai – 2017-11-13T19:17:48.433

6@jinzai the question is about C#, in which long is defined as a signed 64-bit integer, regardless of the platform or the compiler. So in some cases at least, yes, it does depend on the language. – phoog – 2018-02-08T14:30:36.167

2The best book till date I found is CLR via C#...` – Rudresha Parameshappa – 2018-02-11T17:25:56.203

398

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.

Simon_Weaver

Posted 2008-08-10T07:18:02.320

Reputation: 70 081

19Keep in mind that calling a local @string is really rather pointless, since the names of locals are only present in PDBs. Might as well call it _string or something. It makes more sense for things that have names accessible via reflection, where the name of an @string member would be "string". – Roman Starkov – 2013-08-19T10:30:07.807

19Also keep in mind using a reserved word as a variable name is grossly inelegant. – Elton – 2015-10-27T15:16:54.993

38"stack overflow highlights them differently". No more reasons needed :) – Ole Albers – 2016-04-22T13:46:26.670

6The OP does not want to use String or string as a variable name. They asked for an explanation of the difference between these Types. Your answer only serves to add more confusion IMO – Matt Wilko – 2016-07-04T15:14:19.033

343

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

user3296

Posted 2008-08-10T07:18:02.320

Reputation: 389

13by default most people do add this in any ways at the top of the file. VS does this by default in most cases of not all! – IbrarMumtaz – 2010-04-06T16:10:21.793

7By default I add only using statements I require, and explicitly remove all that I don't. Power Productivity Tools > "[x] Remove and Format Usings on save" – JMD – 2016-05-18T16:58:27.260

2@JMD I've modified the .cs template file so it doesn't even have any using statements at the top! I also changed the class template to internal sealed. – ErikE – 2016-12-01T23:48:35.380

280

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

TraumaPony

Posted 2008-08-10T07:18:02.320

Reputation: 7 595

218

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

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.

Ronnie

Posted 2008-08-10T07:18:02.320

Reputation: 6 131

17

+1 for stating that there are more important things in life, I feel here is yet another StackOverflow millions of upvote question about a trivial matter is taking place: http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

– Sebastian – 2014-04-12T19:32:17.643

Just pick one and be consistent. If you work somewhere with a house style, use that. – Alan B – 2015-03-16T16:32:52.987

3unfortunately style is personal preference and may be too expensive to enforce in a large code base across several teams without dedicated code owner. there are always more important matters to take care of rather than string vs String. which brings us back to "more important things in life" – aiodintsov – 2016-02-24T06:51:16.670

178

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

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.

Consider:

String someString; 
string anotherString; 

Anthony Mastrean

Posted 2008-08-10T07:18:02.320

Reputation: 14 123

11Do you also write code like: Int32 i = 1; Rather than int i = 1; ? Seems inconsistent to not use the string alias when it's availble. – bytedev – 2013-01-28T10:49:37.063

23@nashwan: actually, yes, I do use Int32 i=1; intstead of int i = 1; I find the former to be more readable as to my intent: namely that I want a 32 bit signed integer. – NotMe – 2013-02-15T17:30:42.437

5Well I guess it all depends whether the developer thinks they are writing C# code (string) or .NET code (String). Personally I foremost think I'm writing C# (and it's C# that is using .NET). – bytedev – 2014-04-15T13:09:24.393

@NotMe Is it common that you specifically need a 32 bit signed integer, and not just an abstracted integer? – Alex – 2015-04-26T20:27:10.967

5@Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity. – NotMe – 2015-04-27T02:56:54.143

14On the absolute other end of the spectrum, I nearly always just use var – tic – 2016-03-18T15:38:29.100

@NotMe There is no ambiguity. C# defines int as now and forever always being a 32-bit signed integer. It does the same for the other aliases short is always 16-bit signed, etc. – Andy – 2016-10-08T18:52:03.347

173

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

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

TheSoftwareJedi

Posted 2008-08-10T07:18:02.320

Reputation: 25 435

7"string" is not the same as "String". Is means "System.String". So if you use "String" you have to put "using System" to include the namespace – ThiagoAlves – 2011-12-03T16:41:29.877

Jeffrey Richter recommends using the CLR type in all cases (CLR via C#) to avoid exactly the kind of confusion that is taking place here. – Josh – 2008-10-18T17:02:29.503

Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;) – Brad Wilson – 2008-10-18T17:17:18.290

Richter meant that string shouldn't have been an option - Microsoft shouldn't have it in the language. You can't down-vote Richter - he's a legend! :) – Joe Ratzer – 2008-10-18T19:23:07.677

Fair point Jon, but I just happen to agree with Richter on this point about String. And yes, I totally agree - CLR via C# is wonderful! – Joe Ratzer – 2008-10-18T19:51:30.023

I agree that it might have been better to not have the aliases at all. But given that we have them, I think it's fine to use them (but not in method names etc.) – Jon Skeet – 2008-10-19T06:34:50.207

160

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

string is a type in C#.

System.String is a type in the CLR.

When you use C# together with the CLR string will be mapped to 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.

Rasmus Faber

Posted 2008-08-10T07:18:02.320

Reputation: 37 532

Let's be clear about this. 'string' is a reserved alias. It is not a true datatype. It is something that points to something else. You can remove all these aliases (or just never use them) and have a perfectly good programming language. – Donald Airey – 2013-07-08T16:50:49.537

1string is not a type in C#; it is a reserved word that maps to a type in the CLR. – CesarGon – 2011-07-31T17:58:52.050

@CesarGon: According to ECMA-334, section 8.2.1: "C# provides a set of predefined types [...] The predefined reference types are object and string." – Rasmus Faber – 2011-07-31T19:03:30.613

9According to ECMA-334, section 9.4.3, "string" is a keyword. :-) I agree with you that "string" is a type if you focus on the semantics, but I'd say it's a keyword (i.e. a reserved word) if you focus on the syntax. The standard backs both points of view (perhaps too ambiguously!). To me, the OP is about syntax, so I tend to focus on syntax when I look at answers, but I see your point too. Furthermore, your answer, as it stands, may be interpreted as to mean that two different types exist: string and String, when that is not the case. One is a maping to the other. – CesarGon – 2011-07-31T19:30:23.380

148

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.

enter image description here

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

enter image description here

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

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() ;

Shivprasad Koirala

Posted 2008-08-10T07:18:02.320

Reputation: 15 960

22"In short "String" is an alias ( the same thing called with different names) of "string"". This is not correct: the alias is "string". – Xavier Egea – 2014-11-06T12:04:10.447

1when 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. This convention seems to be no more valid: if you use Visual Studio 2015 and try to write String it suggest you to "simplify your code", carrying it to string... – Massimiliano Kraus – 2016-11-04T14:11:45.180

137

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

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

Hallgrim

Posted 2008-08-10T07:18:02.320

Reputation: 11 146

16You do have to include a using System when using String, otherwise you get the following error: The type or namespace name 'String' could not be found (are you missing a using directive or an assembly reference?) – Ronald – 2009-10-16T17:53:00.700

You don't need to prefix System to use String. – Joe Ratzer – 2008-10-18T19:24:16.520

134

Lower case string is an alias for System.String. They are the same in 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.

urini

Posted 2008-08-10T07:18:02.320

Reputation: 19 558

3That's the problem, they are not 'C#' aliases, they are 'C' aliases. There is no native 'string' or 'int' in the C# language, just syntactic sugar. – Donald Airey – 2015-05-29T20:23:54.103

8not sure where "C" came from here, since C# 5 language specification reads "The keyword string is simply an alias for the predefined class System.String." on page 85, paragraph 4.2.4. All high level languages are syntactic sugar over CPU instruction sets and bytecode. – aiodintsov – 2016-02-24T06:57:31.183

122

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

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

Pradeep Kumar Mishra

Posted 2008-08-10T07:18:02.320

Reputation: 9 704

103

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

Lloyd Cotten

Posted 2008-08-10T07:18:02.320

Reputation: 2 118

4I wasn't aware that StyleCop would flag String use - except for static methods. I think that is great as that is how I always use it: string for type declarations and String when I access the static members. – Goyuix – 2011-05-05T18:41:26.473

82

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

Ishmael

Posted 2008-08-10T07:18:02.320

Reputation: 20 355

1

Converting between C# and VB.NET is easy enough as it is. http://www.developerfusion.com/tools/convert/vb-to-csharp/

– grant – 2011-07-01T20:35:22.693

77

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.

RolandK

Posted 2008-08-10T07:18:02.320

Reputation: 410

72

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.

JeeShen Lee

Posted 2008-08-10T07:18:02.320

Reputation: 2 095

65

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.

Joe Alfano

Posted 2008-08-10T07:18:02.320

Reputation: 7 609

59

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.

user576533

Posted 2008-08-10T07:18:02.320

Reputation: 91

58

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.

Michael Ray Lovett

Posted 2008-08-10T07:18:02.320

Reputation: 2 015

Thank you for your life history – Waseem Ahmad Naeem – 2018-05-17T08:40:15.920

52

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.

claudioalpereira

Posted 2008-08-10T07:18:02.320

Reputation: 61

49

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.

Mel

Posted 2008-08-10T07:18:02.320

Reputation: 1 788

44

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.

Similarly, int maps to System.Int32.

Oded

Posted 2008-08-10T07:18:02.320

Reputation: 405 766

In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes) – Alex – 2012-07-25T15:26:08.583

1

@Alex: Nope, see http://msdn.microsoft.com/en-us/library/ya5y69ds.aspx

– flindeberg – 2013-04-17T07:18:49.733

1IntPtr and UIntPtr are the only types that change size according to platform (disregarding actual pointer types like int* and types composed of [U]IntPtrs or actual pointers). – P Daddy – 2013-04-23T21:20:46.097

1http://stackoverflow.com/questions/651956/sizeofint-on-x64 – Craig – 2013-05-23T22:37:50.753

42

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.

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


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

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

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.


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

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.

Jeppe Stig Nielsen

Posted 2008-08-10T07:18:02.320

Reputation: 42 559

4I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String;

and then count the bugs. – Steve – 2015-05-08T00:40:28.807

this is the right answer. string is System.String. String could be anything. – Dave Cousineau – 2018-10-09T20:26:00.263

37

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.

user2771704

Posted 2008-08-10T07:18:02.320

Reputation: 3 573

36

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.

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

Neel

Posted 2008-08-10T07:18:02.320

Reputation: 9 870

1The only tiny difference is that if you use the String class, you need to import the System namespace on top of your file, whereas you don’t have to do this when using the string keyword. – Uttam – 2018-03-04T09:29:34.920

35

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

Coder

Posted 2008-08-10T07:18:02.320

Reputation: 649

32

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

Dot NET

Posted 2008-08-10T07:18:02.320

Reputation: 2 995

26

One argument not mentioned elsewhere to prefer the pascal case String:

System.String is a reference type, and reference types names are pascal case by convention.

Zaid Masud

Posted 2008-08-10T07:18:02.320

Reputation: 8 975

2-1 All type names are pascal case by convention. But C# keywords are all lowercase. – P Daddy – 2013-04-23T21:14:37.070

@PDaddy yes, and string is indeed a C# keyword. The question being asked here is whether to prefer the keyword or the type name. My answer says that, although you can obviously pick the keyword, one argument in favour of using the type name is that they keyword string, which is an alias for the String, is ultimately a reference type.The keyword int, in contrast, is an alias for Int32 which is a value type. – Zaid Masud – 2013-04-24T13:24:26.143

3The casing conventions don't differ between reference types and value types, as evidenced by the Int32 type you yourself mentioned. It doesn't make sense to eschew the keyword in favor of the class name to abide by some imagined restriction that reference types follow different naming conventions than value types. – P Daddy – 2013-04-24T15:34:06.727

@PDaddy yes you are correct. I was carrying over Java conventions here, where primitives are camelCase. – Zaid Masud – 2013-04-24T18:40:21.120

19

Both are the same.The difference is how you use it. Convention is,

string is for variables

String is for calling other String class methods

Like:

string fName = "John";
string lName = "Smith";

string fullName = String.Concat(fName,lName);

if (String.IsNullOrEmpty(fName))
{
  Console.WriteLine("Enter first name");
}

Anuja Lamahewa

Posted 2008-08-10T07:18:02.320

Reputation: 561

2This convention is no more valid: if you use Visual Studio 2015 and try to use String the program suggests you to "simplify your code", carrying it to string. – Massimiliano Kraus – 2016-11-04T14:04:39.363

13

String refers to a string object which comes with various functions for manipulating the contained string.

string refers to a primitive type

In C# they both compile to String but in other languages they do not so you should use String if you want to deal with String objects and string if you want to deal with literals.

Inverted Llama

Posted 2008-08-10T07:18:02.320

Reputation: 403

Care to name these other languages, because I know of none in .net where string != System.String. Also, literal has nothing to do with string vs String... – Andy – 2016-10-08T18:53:24.690

6Completely wrong – Aluan Haddad – 2017-05-19T12:54:00.473

13

In case it's useful to really see there is no difference between string and System.String:

var method1 = typeof(MyClass).GetMethod("TestString1").GetMethodBody().GetILAsByteArray();
var method2 = typeof(MyClass).GetMethod("TestString2").GetMethodBody().GetILAsByteArray();

//...

public string TestString1()
{
    string str = "Hello World!";
    return str;
}

public string TestString2()
{
    String str = "Hello World!";
    return str;
}

Both produce exactly the same IL byte array:

[ 0, 114, 107, 0, 0, 112, 10, 6, 11, 43, 0, 7, 42 ]

tic

Posted 2008-08-10T07:18:02.320

Reputation: 1 009

2I've given you a +1, but your actual methods, when optimise+ is on, are identically return "Hello World!";. To actually ensure the types are "considered" you can use return (string)(object)typeof(string).Name; and return (System.String)(System.Object)typeof(System.String).Name;, which happens to confirm System.Object is identical to object too :-) – Mark Hurd – 2015-10-26T09:03:43.563

11

There is practically 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.

zap92

Posted 2008-08-10T07:18:02.320

Reputation: 154

9

You don't need import namespace (using System;) to use string because it is a global alias of System.String.

To know more about aliases you can check this link.

Teter28

Posted 2008-08-10T07:18:02.320

Reputation: 409

8

There is one practical difference between string and String.

nameof(String); // compiles
nameof(string); // doesn't compile

This is because string is a keyword (an alias in this case) whereas String is a type.

The same is true for the other aliases as well.

| Alias     | Type             |
|-----------|------------------|
|  bool     |  System.Boolean  |
|  byte     |  System.Byte     |
|  sbyte    |  System.SByte    |
|  char     |  System.Char     |
|  decimal  |  System.Decimal  |
|  double   |  System.Double   |
|  float    |  System.Single   |
|  int      |  System.Int32    |
|  uint     |  System.UInt32   |
|  long     |  System.Int64    |
|  ulong    |  System.UInt64   |
|  object   |  System.Object   |
|  short    |  System.Int16    |
|  ushort   |  System.UInt16   |
|  string   |  System.String   |

BanksySan

Posted 2008-08-10T07:18:02.320

Reputation: 10 945

6

In the context of MSDN Documentation, String class is documented like any other data type (e.g., XmlReader, StreamReader) in the BCL.

And string is documented like a keyword (C# Reference) or like any basic C# language construct (e.g., for, while, default).

Reference.

InfZero

Posted 2008-08-10T07:18:02.320

Reputation: 1 283

6

To be honest, in practice usually there is not difference between System.String and string.

All types in C# are objects and all derives from System.Object class. One difference is that string is a C# keyword and String you can use as variable name. System.String is conventional .NET name of this type and string is convenient C# name. Here is simple program which presents difference between System.String and string.

string a = new string(new char[] { 'x', 'y', 'z' });
string b = new String(new char[] { 'x', 'y', 'z' });
String c = new string(new char[] { 'x', 'y', 'z' });
String d = new String(new char[] { 'x', 'y', 'z' });
MessageBox.Show((a.GetType() == typeof(String) && a.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((b.GetType() == typeof(String) && b.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((c.GetType() == typeof(String) && c.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((d.GetType() == typeof(String) && d.GetType() == typeof(string)).ToString()); // shows true

@JonSkeet in my compiler

public enum Foo : UInt32 { }

is working. I've Visual Studio 2015 Community.

hubot

Posted 2008-08-10T07:18:02.320

Reputation: 323

6

First of All, both(string & String) are not same. There is a difference: String is not a keyword and it can be used as Identifier whereas string is a keyword and cannot be used as Identifier.

I am trying to explain with different example : First, when I put "string s;" into Visual Studio and hover over it I get (without the color):
String Definition

That says that string is System.String, right? The documentation is at https://msdn.microsoft.com/en-us/library/362314fe.aspx. The second sentence says "string is an alias for String in the .NET Framework.".

wild coder

Posted 2008-08-10T07:18:02.320

Reputation: 355

5

As pointed out, they are the same thing and string is just an alias to String.

For what it's worth, I use string to declare types - variables, properties, return values and parameters. This is consistent with the use of other system types - int, bool, var etc (although Int32 and Boolean are also correct).

I use String when using the static methods on the String class, like String.Split() or String.IsNullOrEmpty(). I feel that this makes more sense because the methods belong to a class, and it is consistent with how I use other static methods.

yazan_ati

Posted 2008-08-10T07:18:02.320

Reputation: 255

5

There is no difference between the two. You can use either of them in your code.

System.String is a class (reference type) defined the mscorlib in the namespace System. In other words, System.String is a type in the CLR.

string is a keyword in C#

Pritam Jyoti Ray

Posted 2008-08-10T07:18:02.320

Reputation: 219

4

String: A String object is called immutable (read-only) because its value cannot be modified once it has been created. Methods that appear to modify a String object actually return a new String object that contains the modification. If it is necessary to modify the actual contents of a string-like object

string: The string type represents a sequence of zero or more Unicode characters. string is an alias for String in the .NET Framework. string is the intrinsic C# datatype, and is an alias for the system provided type "System.String". The C# specification states that as a matter of style the keyword (string) is preferred over the full system type name (System.String, or String). Although string is a reference type, the equality operators (== and !=) are defined to compare the values of string objects, not references. This makes testing for string equality more intuitive. For example:

Difference between string & String:

  • The string is usually used for declaration while String is used for accessing static string methods
  • You can use 'string' do declare fields, properties etc that use the predefined type 'string', since the C# specification tells me this is good style.
  • You can use 'String' to use system-defined methods, such as String.Compare etc. They are originally defined on 'System.String', not 'string'. 'string' is just an alias in this case.
  • You can also use 'String' or 'System.Int32' when communicating with other system, especially if they are CLR-compliant. i.e. - if I get data from elsewhere, I'd de-serialize it into a System.Int32 rather than an 'int', if the origin by definition was something else than a C# system.

Geeky Ninja

Posted 2008-08-10T07:18:02.320

Reputation: 4 117

1Where are you getting this stuff? This is all complete nonsense: String and string are exactly the same thing. – Jay Sullivan – 2014-09-24T14:56:13.390

4

As far as I know, string is just an alias for System.String, and similar aliases exist for bool, object, int... the only subtle difference is that you can use string without a "using System;" directive, while String requires it (otherwise you should specify System.String in full).

About which is the best to use, I guess it's a matter of taste. Personally I prefer string, but I it's not a religious issue.

Developer

Posted 2008-08-10T07:18:02.320

Reputation: 1 526

4

A string is a sequential collection of characters that is used to represent text.

A String object is a sequential collection of System.Char objects that represent a string; a System.Char object corresponds to a UTF-16 code unit.

The value of the String object is the content of the sequential collection of System.Char objects, and that value is immutable (that is, it is read-only).

For more information about the immutability of strings, see the Immutability and the StringBuilder class section in msdn.

The maximum size of a String object in memory is 2GB, or about 1 billion characters.

Note : answer is extracted from msdn help section. You can see the full content here in msdn String Class topic under Remarks section

Jineesh Uvantavida

Posted 2008-08-10T07:18:02.320

Reputation: 349

4

Jeffrey Richter written:

Another way to think of this is that the C# compiler automatically assumes that you have the following using directives in all of your source code files:

using int = System.Int32;
using uint = System.UInt32;
using string = System.String;
...

I’ve seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used.

v.slobodzian

Posted 2008-08-10T07:18:02.320

Reputation: 88

3

string is equal to System.String
in VS2015 if you write this

System.String str;

Than compiler will show potential fix to optimize it and after applying that fixe it will look like this

string str;

Saurabh

Posted 2008-08-10T07:18:02.320

Reputation: 526

3

I prefer to use string because this type is used so much that I don't want the syntax highlighter blending it in with all the other classes. Although it is a class it is used more like a primitive therefore I think the different highlight colour is appropriate.

If you right click on the string keyword and select Go to definition from the context menu it'll take you to the String class - it's just syntactic sugar but it improves readability imo.

DavidWainwright

Posted 2008-08-10T07:18:02.320

Reputation: 2 027

3

In C#, string is the short version of System.String (String). They basically mean the same thing.

Like someone mentioned, it's just like bool and Boolean, not much difference..

Taslim

Posted 2008-08-10T07:18:02.320

Reputation: 1 118

2

string is an alias for String in the .NET Framework.

Where "String" is in fact System.String.

I would say that they are interchangeable and there is no difference when and where you should use one or the other.

It would be better to be consistent with which one you did use though.

For what it's worth, I use string to declare types - variables, properties, return values and parameters. This is consistent with the use of other system types - int, bool, var etc (although Int32 and Boolean are also correct).

I use String when using the static methods on the String class, like String.Split() or String.IsNullOrEmpty(). I feel that this makes more sense because the methods belong to a class, and it is consistent with how I use other static methods.

Vijay Singh Rana

Posted 2008-08-10T07:18:02.320

Reputation: 645

2

String : Represent a class

string : Represent an alias

It's just a coding convention from microsoft .

sayah imad

Posted 2008-08-10T07:18:02.320

Reputation: 37

2

string is short name of System.String. String or System.String is name of string in CTS(Common Type System).

Həsən Cəfərov

Posted 2008-08-10T07:18:02.320

Reputation: 442

1

As you already know string is just alias for System.String. But what should I use? it just personal preference.

In my case, I love to use string rather than use System.String because String requires a namespace using System; or a full name System.String.

So I believe the alias string was created for simplicity and I love it!

Jaider

Posted 2008-08-10T07:18:02.320

Reputation: 8 805

1

string is a shortcut for System.String. The only difference is that you don´t need to reference to System.String namespace. So would be better using string than String.

BerBar

Posted 2008-08-10T07:18:02.320

Reputation: 107

0

String is the class of string. If you remove System namespace from using statements, you can see that String has gone but string is still here. string is keyword for String. Like
int and Int32
short and Int16
long and Int64

So the keywords are just some words that uses a class. These keywords are specified by C#(so Microsoft, because C# is Microsoft's). Briefly, there's no difference. Using string or String. That doesn't matter. They are same.

Burak Yeniçeri

Posted 2008-08-10T07:18:02.320

Reputation: 28

0

it is common practice to declare a variable using C# keywords. In fact, every C# type has an equivalent in .NET. As another example, short and int in C# map to Int16 and Int32 in .NET. So, technically there is no difference between string and String, but In C#, string is an alias for the String class in .NET framework.

Braham Prakash Yadav

Posted 2008-08-10T07:18:02.320

Reputation: 24

-5

String is nothing but an alias for String class. If you want to use the functions of the string class then you should use String else you should stick to string. For example, if you want to format a string then you should use the String class to use String.Format() but if you simple want to define the string then you should use string test=""; Please note that both of them are reference type.

Pratikgcet

Posted 2008-08-10T07:18:02.320

Reputation: 11