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












5801















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?










share|improve this question




















  • 45





    @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
    Dec 2 '14 at 3:05








  • 79





    @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
    Dec 2 '14 at 8:22








  • 57





    You can use string without a using directive for System. You can't do that with String.

    – Wilsu
    Nov 30 '15 at 8:52








  • 7





    For 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
    Dec 20 '16 at 0:24








  • 2





    @Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

    – Craig
    Dec 8 '18 at 2:14


















5801















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?










share|improve this question




















  • 45





    @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
    Dec 2 '14 at 3:05








  • 79





    @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
    Dec 2 '14 at 8:22








  • 57





    You can use string without a using directive for System. You can't do that with String.

    – Wilsu
    Nov 30 '15 at 8:52








  • 7





    For 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
    Dec 20 '16 at 0:24








  • 2





    @Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

    – Craig
    Dec 8 '18 at 2:14
















5801












5801








5801


884






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?










share|improve this question
















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?







c# .net string types alias






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 27 '18 at 16:42


























community wiki





23 revs, 19 users 12%
Peter O.









  • 45





    @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
    Dec 2 '14 at 3:05








  • 79





    @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
    Dec 2 '14 at 8:22








  • 57





    You can use string without a using directive for System. You can't do that with String.

    – Wilsu
    Nov 30 '15 at 8:52








  • 7





    For 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
    Dec 20 '16 at 0:24








  • 2





    @Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

    – Craig
    Dec 8 '18 at 2:14
















  • 45





    @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
    Dec 2 '14 at 3:05








  • 79





    @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
    Dec 2 '14 at 8:22








  • 57





    You can use string without a using directive for System. You can't do that with String.

    – Wilsu
    Nov 30 '15 at 8:52








  • 7





    For 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
    Dec 20 '16 at 0:24








  • 2





    @Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

    – Craig
    Dec 8 '18 at 2:14










45




45





@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
Dec 2 '14 at 3:05







@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
Dec 2 '14 at 3:05






79




79





@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
Dec 2 '14 at 8:22







@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
Dec 2 '14 at 8:22






57




57





You can use string without a using directive for System. You can't do that with String.

– Wilsu
Nov 30 '15 at 8:52







You can use string without a using directive for System. You can't do that with String.

– Wilsu
Nov 30 '15 at 8:52






7




7





For 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
Dec 20 '16 at 0:24







For 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
Dec 20 '16 at 0:24






2




2





@Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

– Craig
Dec 8 '18 at 2:14







@Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing.

– Craig
Dec 8 '18 at 2:14














57 Answers
57






active

oldest

votes













1 2
next












5472














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.






share|improve this answer





















  • 133





    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) - stylecop.soyuz5.com/SA1121.html

    – Dominic Zukiewicz
    May 22 '12 at 22:36








  • 102





    I 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
    Oct 12 '12 at 23:25






  • 22





    Visual 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
    Dec 22 '14 at 5:21






  • 24





    As 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
    May 29 '15 at 14:30






  • 25





    Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

    – Jeroen Vannevel
    Feb 5 '16 at 20:38



















3194















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.






share|improve this answer





















  • 71





    The 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
    Oct 19 '08 at 2:00






  • 131





    It'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
    Oct 19 '08 at 6:34






  • 28





    @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
    Sep 9 '11 at 21:27






  • 32





    One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

    – Sanjeev Rai
    Jun 5 '13 at 7:09






  • 30





    @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
    Jun 5 '13 at 7:18



















644














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






share|improve this answer





















  • 2





    ` If 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
    Nov 16 '15 at 8:31






  • 2





    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
    Apr 28 '16 at 11:41








  • 1





    @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
    Jan 21 '17 at 17:39








  • 2





    @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

    – Craig
    Dec 8 '18 at 2:47






  • 3





    @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

    – Nyerguds
    Dec 9 '18 at 2:29





















453














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.






share|improve this answer





















  • 15





    The second point sounds actually like a reason not to use string, int etc.

    – MauganRa
    Jun 15 '15 at 15:37






  • 12





    @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
    Sep 15 '15 at 17:48






  • 25





    "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
    Sep 21 '15 at 22:11






  • 10





    +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
    Mar 2 '17 at 10:41






  • 8





    @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
    Feb 8 '18 at 14:30



















410














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.






share|improve this answer





















  • 19





    Keep 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
    Aug 19 '13 at 10:30






  • 19





    Also keep in mind using a reserved word as a variable name is grossly inelegant.

    – Elton
    Oct 27 '15 at 15:16






  • 39





    "stack overflow highlights them differently". No more reasons needed :)

    – Ole Albers
    Apr 22 '16 at 13:46






  • 7





    The 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
    Jul 4 '16 at 15:14






  • 1





    @craig if you were writing software to teach people how to tie knots?

    – Simon_Weaver
    Dec 9 '18 at 3:31



















354














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






share|improve this answer





















  • 13





    by 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
    Apr 6 '10 at 16:10






  • 7





    By 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
    May 18 '16 at 16:58






  • 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
    Dec 1 '16 at 23:48











  • @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

    – mg30rg
    Feb 19 at 14:45



















287














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






share|improve this answer

































    228














    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.






    share|improve this answer





















    • 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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

      – Sebastian
      Apr 12 '14 at 19:32













    • Just pick one and be consistent. If you work somewhere with a house style, use that.

      – Alan B
      Mar 16 '15 at 16:32






    • 3





      unfortunately 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
      Feb 24 '16 at 6:51











    • This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

      – PerpetualJ
      Jan 2 at 19:18





















    188















    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;





    share|improve this answer





















    • 11





      Do 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
      Jan 28 '13 at 10:49






    • 24





      @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
      Feb 15 '13 at 17:30






    • 5





      Well 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
      Apr 15 '14 at 13:09






    • 6





      @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

      – NotMe
      Apr 27 '15 at 2:56






    • 14





      On the absolute other end of the spectrum, I nearly always just use var

      – tic
      Mar 18 '16 at 15:38



















    179














    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






    share|improve this answer


























    • 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
      Oct 18 '08 at 17:02











    • Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

      – Brad Wilson
      Oct 18 '08 at 17:17











    • 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
      Oct 18 '08 at 19:23











    • 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
      Oct 18 '08 at 19:51






    • 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
      Dec 3 '11 at 16:41



















    166














    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.






    share|improve this answer





















    • 1





      string is not a type in C#; it is a reserved word that maps to a type in the CLR.

      – CesarGon
      Jul 31 '11 at 17:58











    • @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
      Jul 31 '11 at 19:03






    • 9





      According 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
      Jul 31 '11 at 19:30













    • 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
      Jul 8 '13 at 16:50



















    153














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





    share|improve this answer





















    • 24





      "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
      Nov 6 '14 at 12:04






    • 2





      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. 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
      Nov 4 '16 at 14:11



















    142














    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.






    share|improve this answer


























    • You don't need to prefix System to use String.

      – Joe Ratzer
      Oct 18 '08 at 19:24






    • 17





      You 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
      Oct 16 '09 at 17:53



















    142














    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.






    share|improve this answer





















    • 4





      That'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
      May 29 '15 at 20:23








    • 10





      not 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
      Feb 24 '16 at 6:57



















    128














    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






    share|improve this answer

































      108














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






      share|improve this answer





















      • 4





        I 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
        May 5 '11 at 18:41



















      88














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






      share|improve this answer





















      • 1





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

        – grant
        Jul 1 '11 at 20:35



















      82














      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.






      share|improve this answer

































        77














        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.






        share|improve this answer

































          69














          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.






          share|improve this answer

































            67














            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’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. Similarly,
              I’ve heard some developers say that int represents a 32-bit integer when the application
              is running on a 32-bit OS and that it represents a 64-bit integer when the application
              is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
              to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
              code is running on. If programmers would use Int32 in their code, then this potential
              confusion is also eliminated.


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


            • Many programmers that use C# exclusively tend to forget that other programming
              languages can be used against the CLR, and because of this, C#-isms creep into the
              class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
              developers on the FCL team have now introduced methods into the library such as
              Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
              in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
              LongCount method.





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






            share|improve this answer

































              63














              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.






              share|improve this answer

































                63














                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.






                share|improve this answer


























                • Thank you for your life history

                  – user4350912
                  May 17 '18 at 8:40



















                57














                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.






                share|improve this answer

































                  48














                  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.






                  share|improve this answer


























                  • In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                    – Alex
                    Jul 25 '12 at 15:26






                  • 1





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

                    – flindeberg
                    Apr 17 '13 at 7:18






                  • 1





                    IntPtr 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
                    Apr 23 '13 at 21:20






                  • 1





                    stackoverflow.com/questions/651956/sizeofint-on-x64

                    – Craig
                    May 23 '13 at 22:37



















                  46














                  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.






                  share|improve this answer





















                  • 4





                    I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                    – Steve
                    May 8 '15 at 0:40








                  • 1





                    this is the right answer. string is System.String. String could be anything.

                    – Dave Cousineau
                    Oct 9 '18 at 20:26



















                  41














                  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.







                  share|improve this answer

































                    40














                    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)





                    share|improve this answer





















                    • 1





                      The 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
                      Mar 4 '18 at 9:29



















                    38














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






                    share|improve this answer

































                      33














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






                      share|improve this answer





























                        1 2
                        next


                        protected by Community Apr 22 '12 at 14:57



                        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?














                        57 Answers
                        57






                        active

                        oldest

                        votes








                        57 Answers
                        57






                        active

                        oldest

                        votes









                        active

                        oldest

                        votes






                        active

                        oldest

                        votes








                        1 2
                        next










                        5472














                        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.






                        share|improve this answer





















                        • 133





                          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) - stylecop.soyuz5.com/SA1121.html

                          – Dominic Zukiewicz
                          May 22 '12 at 22:36








                        • 102





                          I 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
                          Oct 12 '12 at 23:25






                        • 22





                          Visual 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
                          Dec 22 '14 at 5:21






                        • 24





                          As 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
                          May 29 '15 at 14:30






                        • 25





                          Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                          – Jeroen Vannevel
                          Feb 5 '16 at 20:38
















                        5472














                        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.






                        share|improve this answer





















                        • 133





                          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) - stylecop.soyuz5.com/SA1121.html

                          – Dominic Zukiewicz
                          May 22 '12 at 22:36








                        • 102





                          I 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
                          Oct 12 '12 at 23:25






                        • 22





                          Visual 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
                          Dec 22 '14 at 5:21






                        • 24





                          As 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
                          May 29 '15 at 14:30






                        • 25





                          Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                          – Jeroen Vannevel
                          Feb 5 '16 at 20:38














                        5472












                        5472








                        5472







                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Jan 22 at 18:50


























                        community wiki





                        26 revs, 21 users 26%
                        Derek Park









                        • 133





                          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) - stylecop.soyuz5.com/SA1121.html

                          – Dominic Zukiewicz
                          May 22 '12 at 22:36








                        • 102





                          I 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
                          Oct 12 '12 at 23:25






                        • 22





                          Visual 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
                          Dec 22 '14 at 5:21






                        • 24





                          As 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
                          May 29 '15 at 14:30






                        • 25





                          Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                          – Jeroen Vannevel
                          Feb 5 '16 at 20:38














                        • 133





                          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) - stylecop.soyuz5.com/SA1121.html

                          – Dominic Zukiewicz
                          May 22 '12 at 22:36








                        • 102





                          I 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
                          Oct 12 '12 at 23:25






                        • 22





                          Visual 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
                          Dec 22 '14 at 5:21






                        • 24





                          As 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
                          May 29 '15 at 14:30






                        • 25





                          Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                          – Jeroen Vannevel
                          Feb 5 '16 at 20:38








                        133




                        133





                        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) - stylecop.soyuz5.com/SA1121.html

                        – Dominic Zukiewicz
                        May 22 '12 at 22:36







                        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) - stylecop.soyuz5.com/SA1121.html

                        – Dominic Zukiewicz
                        May 22 '12 at 22:36






                        102




                        102





                        I 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
                        Oct 12 '12 at 23:25





                        I 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
                        Oct 12 '12 at 23:25




                        22




                        22





                        Visual 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
                        Dec 22 '14 at 5:21





                        Visual 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
                        Dec 22 '14 at 5:21




                        24




                        24





                        As 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
                        May 29 '15 at 14:30





                        As 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
                        May 29 '15 at 14:30




                        25




                        25





                        Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                        – Jeroen Vannevel
                        Feb 5 '16 at 20:38





                        Could you add a remark that there is, in fact, a difference? For example: nameof(string) won't compile whereas nameof(String) will.

                        – Jeroen Vannevel
                        Feb 5 '16 at 20:38













                        3194















                        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.






                        share|improve this answer





















                        • 71





                          The 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
                          Oct 19 '08 at 2:00






                        • 131





                          It'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
                          Oct 19 '08 at 6:34






                        • 28





                          @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
                          Sep 9 '11 at 21:27






                        • 32





                          One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                          – Sanjeev Rai
                          Jun 5 '13 at 7:09






                        • 30





                          @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
                          Jun 5 '13 at 7:18
















                        3194















                        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.






                        share|improve this answer





















                        • 71





                          The 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
                          Oct 19 '08 at 2:00






                        • 131





                          It'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
                          Oct 19 '08 at 6:34






                        • 28





                          @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
                          Sep 9 '11 at 21:27






                        • 32





                          One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                          – Sanjeev Rai
                          Jun 5 '13 at 7:09






                        • 30





                          @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
                          Jun 5 '13 at 7:18














                        3194












                        3194








                        3194








                        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.






                        share|improve this answer
















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Jan 20 '18 at 14:02


























                        community wiki





                        12 revs, 8 users 63%
                        Jon Skeet









                        • 71





                          The 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
                          Oct 19 '08 at 2:00






                        • 131





                          It'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
                          Oct 19 '08 at 6:34






                        • 28





                          @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
                          Sep 9 '11 at 21:27






                        • 32





                          One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                          – Sanjeev Rai
                          Jun 5 '13 at 7:09






                        • 30





                          @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
                          Jun 5 '13 at 7:18














                        • 71





                          The 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
                          Oct 19 '08 at 2:00






                        • 131





                          It'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
                          Oct 19 '08 at 6:34






                        • 28





                          @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
                          Sep 9 '11 at 21:27






                        • 32





                          One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                          – Sanjeev Rai
                          Jun 5 '13 at 7:09






                        • 30





                          @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
                          Jun 5 '13 at 7:18








                        71




                        71





                        The 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
                        Oct 19 '08 at 2:00





                        The 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
                        Oct 19 '08 at 2:00




                        131




                        131





                        It'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
                        Oct 19 '08 at 6:34





                        It'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
                        Oct 19 '08 at 6:34




                        28




                        28





                        @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
                        Sep 9 '11 at 21: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
                        Sep 9 '11 at 21:27




                        32




                        32





                        One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                        – Sanjeev Rai
                        Jun 5 '13 at 7:09





                        One 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, but String String="hi";` is acceptable, as String is an identifire not a keyword.

                        – Sanjeev Rai
                        Jun 5 '13 at 7:09




                        30




                        30





                        @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
                        Jun 5 '13 at 7:18





                        @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
                        Jun 5 '13 at 7:18











                        644














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






                        share|improve this answer





















                        • 2





                          ` If 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
                          Nov 16 '15 at 8:31






                        • 2





                          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
                          Apr 28 '16 at 11:41








                        • 1





                          @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
                          Jan 21 '17 at 17:39








                        • 2





                          @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                          – Craig
                          Dec 8 '18 at 2:47






                        • 3





                          @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                          – Nyerguds
                          Dec 9 '18 at 2:29


















                        644














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






                        share|improve this answer





















                        • 2





                          ` If 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
                          Nov 16 '15 at 8:31






                        • 2





                          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
                          Apr 28 '16 at 11:41








                        • 1





                          @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
                          Jan 21 '17 at 17:39








                        • 2





                          @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                          – Craig
                          Dec 8 '18 at 2:47






                        • 3





                          @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                          – Nyerguds
                          Dec 9 '18 at 2:29
















                        644












                        644








                        644







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






                        share|improve this answer















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







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Dec 3 '11 at 19:53


























                        community wiki





                        3 revs, 3 users 57%
                        artur02










                        • 2





                          ` If 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
                          Nov 16 '15 at 8:31






                        • 2





                          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
                          Apr 28 '16 at 11:41








                        • 1





                          @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
                          Jan 21 '17 at 17:39








                        • 2





                          @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                          – Craig
                          Dec 8 '18 at 2:47






                        • 3





                          @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                          – Nyerguds
                          Dec 9 '18 at 2:29
















                        • 2





                          ` If 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
                          Nov 16 '15 at 8:31






                        • 2





                          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
                          Apr 28 '16 at 11:41








                        • 1





                          @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
                          Jan 21 '17 at 17:39








                        • 2





                          @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                          – Craig
                          Dec 8 '18 at 2:47






                        • 3





                          @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                          – Nyerguds
                          Dec 9 '18 at 2:29










                        2




                        2





                        ` If 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
                        Nov 16 '15 at 8:31





                        ` If 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
                        Nov 16 '15 at 8:31




                        2




                        2





                        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
                        Apr 28 '16 at 11:41







                        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
                        Apr 28 '16 at 11:41






                        1




                        1





                        @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
                        Jan 21 '17 at 17:39







                        @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
                        Jan 21 '17 at 17:39






                        2




                        2





                        @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                        – Craig
                        Dec 8 '18 at 2:47





                        @Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-)

                        – Craig
                        Dec 8 '18 at 2:47




                        3




                        3





                        @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                        – Nyerguds
                        Dec 9 '18 at 2:29







                        @Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long

                        – Nyerguds
                        Dec 9 '18 at 2:29













                        453














                        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.






                        share|improve this answer





















                        • 15





                          The second point sounds actually like a reason not to use string, int etc.

                          – MauganRa
                          Jun 15 '15 at 15:37






                        • 12





                          @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
                          Sep 15 '15 at 17:48






                        • 25





                          "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
                          Sep 21 '15 at 22:11






                        • 10





                          +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
                          Mar 2 '17 at 10:41






                        • 8





                          @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
                          Feb 8 '18 at 14:30
















                        453














                        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.






                        share|improve this answer





















                        • 15





                          The second point sounds actually like a reason not to use string, int etc.

                          – MauganRa
                          Jun 15 '15 at 15:37






                        • 12





                          @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
                          Sep 15 '15 at 17:48






                        • 25





                          "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
                          Sep 21 '15 at 22:11






                        • 10





                          +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
                          Mar 2 '17 at 10:41






                        • 8





                          @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
                          Feb 8 '18 at 14:30














                        453












                        453








                        453







                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Jul 4 '18 at 11:05


























                        community wiki





                        4 revs, 3 users 89%
                        Luke Foust









                        • 15





                          The second point sounds actually like a reason not to use string, int etc.

                          – MauganRa
                          Jun 15 '15 at 15:37






                        • 12





                          @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
                          Sep 15 '15 at 17:48






                        • 25





                          "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
                          Sep 21 '15 at 22:11






                        • 10





                          +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
                          Mar 2 '17 at 10:41






                        • 8





                          @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
                          Feb 8 '18 at 14:30














                        • 15





                          The second point sounds actually like a reason not to use string, int etc.

                          – MauganRa
                          Jun 15 '15 at 15:37






                        • 12





                          @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
                          Sep 15 '15 at 17:48






                        • 25





                          "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
                          Sep 21 '15 at 22:11






                        • 10





                          +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
                          Mar 2 '17 at 10:41






                        • 8





                          @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
                          Feb 8 '18 at 14:30








                        15




                        15





                        The second point sounds actually like a reason not to use string, int etc.

                        – MauganRa
                        Jun 15 '15 at 15:37





                        The second point sounds actually like a reason not to use string, int etc.

                        – MauganRa
                        Jun 15 '15 at 15:37




                        12




                        12





                        @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
                        Sep 15 '15 at 17:48





                        @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
                        Sep 15 '15 at 17:48




                        25




                        25





                        "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
                        Sep 21 '15 at 22:11





                        "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
                        Sep 21 '15 at 22:11




                        10




                        10





                        +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
                        Mar 2 '17 at 10:41





                        +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
                        Mar 2 '17 at 10:41




                        8




                        8





                        @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
                        Feb 8 '18 at 14:30





                        @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
                        Feb 8 '18 at 14:30











                        410














                        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.






                        share|improve this answer





















                        • 19





                          Keep 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
                          Aug 19 '13 at 10:30






                        • 19





                          Also keep in mind using a reserved word as a variable name is grossly inelegant.

                          – Elton
                          Oct 27 '15 at 15:16






                        • 39





                          "stack overflow highlights them differently". No more reasons needed :)

                          – Ole Albers
                          Apr 22 '16 at 13:46






                        • 7





                          The 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
                          Jul 4 '16 at 15:14






                        • 1





                          @craig if you were writing software to teach people how to tie knots?

                          – Simon_Weaver
                          Dec 9 '18 at 3:31
















                        410














                        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.






                        share|improve this answer





















                        • 19





                          Keep 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
                          Aug 19 '13 at 10:30






                        • 19





                          Also keep in mind using a reserved word as a variable name is grossly inelegant.

                          – Elton
                          Oct 27 '15 at 15:16






                        • 39





                          "stack overflow highlights them differently". No more reasons needed :)

                          – Ole Albers
                          Apr 22 '16 at 13:46






                        • 7





                          The 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
                          Jul 4 '16 at 15:14






                        • 1





                          @craig if you were writing software to teach people how to tie knots?

                          – Simon_Weaver
                          Dec 9 '18 at 3:31














                        410












                        410








                        410







                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Dec 27 '17 at 17:33


























                        community wiki





                        5 revs, 4 users 79%
                        Simon_Weaver









                        • 19





                          Keep 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
                          Aug 19 '13 at 10:30






                        • 19





                          Also keep in mind using a reserved word as a variable name is grossly inelegant.

                          – Elton
                          Oct 27 '15 at 15:16






                        • 39





                          "stack overflow highlights them differently". No more reasons needed :)

                          – Ole Albers
                          Apr 22 '16 at 13:46






                        • 7





                          The 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
                          Jul 4 '16 at 15:14






                        • 1





                          @craig if you were writing software to teach people how to tie knots?

                          – Simon_Weaver
                          Dec 9 '18 at 3:31














                        • 19





                          Keep 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
                          Aug 19 '13 at 10:30






                        • 19





                          Also keep in mind using a reserved word as a variable name is grossly inelegant.

                          – Elton
                          Oct 27 '15 at 15:16






                        • 39





                          "stack overflow highlights them differently". No more reasons needed :)

                          – Ole Albers
                          Apr 22 '16 at 13:46






                        • 7





                          The 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
                          Jul 4 '16 at 15:14






                        • 1





                          @craig if you were writing software to teach people how to tie knots?

                          – Simon_Weaver
                          Dec 9 '18 at 3:31








                        19




                        19





                        Keep 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
                        Aug 19 '13 at 10:30





                        Keep 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
                        Aug 19 '13 at 10:30




                        19




                        19





                        Also keep in mind using a reserved word as a variable name is grossly inelegant.

                        – Elton
                        Oct 27 '15 at 15:16





                        Also keep in mind using a reserved word as a variable name is grossly inelegant.

                        – Elton
                        Oct 27 '15 at 15:16




                        39




                        39





                        "stack overflow highlights them differently". No more reasons needed :)

                        – Ole Albers
                        Apr 22 '16 at 13:46





                        "stack overflow highlights them differently". No more reasons needed :)

                        – Ole Albers
                        Apr 22 '16 at 13:46




                        7




                        7





                        The 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
                        Jul 4 '16 at 15:14





                        The 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
                        Jul 4 '16 at 15:14




                        1




                        1





                        @craig if you were writing software to teach people how to tie knots?

                        – Simon_Weaver
                        Dec 9 '18 at 3:31





                        @craig if you were writing software to teach people how to tie knots?

                        – Simon_Weaver
                        Dec 9 '18 at 3:31











                        354














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






                        share|improve this answer





















                        • 13





                          by 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
                          Apr 6 '10 at 16:10






                        • 7





                          By 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
                          May 18 '16 at 16:58






                        • 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
                          Dec 1 '16 at 23:48











                        • @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                          – mg30rg
                          Feb 19 at 14:45
















                        354














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






                        share|improve this answer





















                        • 13





                          by 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
                          Apr 6 '10 at 16:10






                        • 7





                          By 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
                          May 18 '16 at 16:58






                        • 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
                          Dec 1 '16 at 23:48











                        • @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                          – mg30rg
                          Feb 19 at 14:45














                        354












                        354








                        354







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






                        share|improve this answer















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







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Oct 3 '16 at 18:32


























                        community wiki





                        3 revs, 3 users 50%
                        user3296









                        • 13





                          by 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
                          Apr 6 '10 at 16:10






                        • 7





                          By 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
                          May 18 '16 at 16:58






                        • 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
                          Dec 1 '16 at 23:48











                        • @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                          – mg30rg
                          Feb 19 at 14:45














                        • 13





                          by 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
                          Apr 6 '10 at 16:10






                        • 7





                          By 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
                          May 18 '16 at 16:58






                        • 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
                          Dec 1 '16 at 23:48











                        • @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                          – mg30rg
                          Feb 19 at 14:45








                        13




                        13





                        by 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
                        Apr 6 '10 at 16:10





                        by 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
                        Apr 6 '10 at 16:10




                        7




                        7





                        By 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
                        May 18 '16 at 16:58





                        By 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
                        May 18 '16 at 16:58




                        2




                        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
                        Dec 1 '16 at 23:48





                        @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
                        Dec 1 '16 at 23:48













                        @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                        – mg30rg
                        Feb 19 at 14:45





                        @JMD I hate that feature. It sometimes makes changes on otherwise untouched files making it difficult to see what actual changes a changeset contains. Of course I usually remove "using spam", but only actively, not automatically.

                        – mg30rg
                        Feb 19 at 14:45











                        287














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






                        share|improve this answer






























                          287














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






                          share|improve this answer




























                            287












                            287








                            287







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






                            share|improve this answer















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







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Nov 19 '11 at 9:36


























                            community wiki





                            2 revs, 2 users 67%
                            TraumaPony

























                                228














                                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.






                                share|improve this answer





















                                • 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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                  – Sebastian
                                  Apr 12 '14 at 19:32













                                • Just pick one and be consistent. If you work somewhere with a house style, use that.

                                  – Alan B
                                  Mar 16 '15 at 16:32






                                • 3





                                  unfortunately 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
                                  Feb 24 '16 at 6:51











                                • This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                  – PerpetualJ
                                  Jan 2 at 19:18


















                                228














                                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.






                                share|improve this answer





















                                • 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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                  – Sebastian
                                  Apr 12 '14 at 19:32













                                • Just pick one and be consistent. If you work somewhere with a house style, use that.

                                  – Alan B
                                  Mar 16 '15 at 16:32






                                • 3





                                  unfortunately 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
                                  Feb 24 '16 at 6:51











                                • This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                  – PerpetualJ
                                  Jan 2 at 19:18
















                                228












                                228








                                228







                                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.






                                share|improve this answer















                                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.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Feb 6 '18 at 12:39


























                                community wiki





                                3 revs, 3 users 73%
                                Ronnie









                                • 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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                  – Sebastian
                                  Apr 12 '14 at 19:32













                                • Just pick one and be consistent. If you work somewhere with a house style, use that.

                                  – Alan B
                                  Mar 16 '15 at 16:32






                                • 3





                                  unfortunately 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
                                  Feb 24 '16 at 6:51











                                • This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                  – PerpetualJ
                                  Jan 2 at 19:18
















                                • 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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                  – Sebastian
                                  Apr 12 '14 at 19:32













                                • Just pick one and be consistent. If you work somewhere with a house style, use that.

                                  – Alan B
                                  Mar 16 '15 at 16:32






                                • 3





                                  unfortunately 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
                                  Feb 24 '16 at 6:51











                                • This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                  – PerpetualJ
                                  Jan 2 at 19:18










                                17




                                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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                – Sebastian
                                Apr 12 '14 at 19:32







                                +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: en.wikipedia.org/wiki/Parkinson's_law_of_triviality

                                – Sebastian
                                Apr 12 '14 at 19:32















                                Just pick one and be consistent. If you work somewhere with a house style, use that.

                                – Alan B
                                Mar 16 '15 at 16:32





                                Just pick one and be consistent. If you work somewhere with a house style, use that.

                                – Alan B
                                Mar 16 '15 at 16:32




                                3




                                3





                                unfortunately 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
                                Feb 24 '16 at 6:51





                                unfortunately 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
                                Feb 24 '16 at 6:51













                                This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                – PerpetualJ
                                Jan 2 at 19:18







                                This is definitely a preference thing; for example: I prefer to use short, int, ushort, uint instead of Int16, etc. Mostly because this is how I learned. Granted, the Int16 is easier to immediately understand for those with less experience. +1 From me!

                                – PerpetualJ
                                Jan 2 at 19:18













                                188















                                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;





                                share|improve this answer





















                                • 11





                                  Do 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
                                  Jan 28 '13 at 10:49






                                • 24





                                  @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
                                  Feb 15 '13 at 17:30






                                • 5





                                  Well 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
                                  Apr 15 '14 at 13:09






                                • 6





                                  @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                  – NotMe
                                  Apr 27 '15 at 2:56






                                • 14





                                  On the absolute other end of the spectrum, I nearly always just use var

                                  – tic
                                  Mar 18 '16 at 15:38
















                                188















                                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;





                                share|improve this answer





















                                • 11





                                  Do 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
                                  Jan 28 '13 at 10:49






                                • 24





                                  @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
                                  Feb 15 '13 at 17:30






                                • 5





                                  Well 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
                                  Apr 15 '14 at 13:09






                                • 6





                                  @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                  – NotMe
                                  Apr 27 '15 at 2:56






                                • 14





                                  On the absolute other end of the spectrum, I nearly always just use var

                                  – tic
                                  Mar 18 '16 at 15:38














                                188












                                188








                                188








                                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;





                                share|improve this answer
















                                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;






                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Sep 28 '16 at 11:58


























                                community wiki





                                4 revs, 4 users 50%
                                StuartLC









                                • 11





                                  Do 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
                                  Jan 28 '13 at 10:49






                                • 24





                                  @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
                                  Feb 15 '13 at 17:30






                                • 5





                                  Well 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
                                  Apr 15 '14 at 13:09






                                • 6





                                  @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                  – NotMe
                                  Apr 27 '15 at 2:56






                                • 14





                                  On the absolute other end of the spectrum, I nearly always just use var

                                  – tic
                                  Mar 18 '16 at 15:38














                                • 11





                                  Do 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
                                  Jan 28 '13 at 10:49






                                • 24





                                  @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
                                  Feb 15 '13 at 17:30






                                • 5





                                  Well 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
                                  Apr 15 '14 at 13:09






                                • 6





                                  @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                  – NotMe
                                  Apr 27 '15 at 2:56






                                • 14





                                  On the absolute other end of the spectrum, I nearly always just use var

                                  – tic
                                  Mar 18 '16 at 15:38








                                11




                                11





                                Do 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
                                Jan 28 '13 at 10:49





                                Do 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
                                Jan 28 '13 at 10:49




                                24




                                24





                                @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
                                Feb 15 '13 at 17:30





                                @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
                                Feb 15 '13 at 17:30




                                5




                                5





                                Well 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
                                Apr 15 '14 at 13:09





                                Well 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
                                Apr 15 '14 at 13:09




                                6




                                6





                                @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                – NotMe
                                Apr 27 '15 at 2:56





                                @Alex: my point was simply that I prefer to be very specific in my coding in order to remove ambiguity.

                                – NotMe
                                Apr 27 '15 at 2:56




                                14




                                14





                                On the absolute other end of the spectrum, I nearly always just use var

                                – tic
                                Mar 18 '16 at 15:38





                                On the absolute other end of the spectrum, I nearly always just use var

                                – tic
                                Mar 18 '16 at 15:38











                                179














                                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






                                share|improve this answer


























                                • 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
                                  Oct 18 '08 at 17:02











                                • Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                  – Brad Wilson
                                  Oct 18 '08 at 17:17











                                • 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
                                  Oct 18 '08 at 19:23











                                • 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
                                  Oct 18 '08 at 19:51






                                • 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
                                  Dec 3 '11 at 16:41
















                                179














                                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






                                share|improve this answer


























                                • 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
                                  Oct 18 '08 at 17:02











                                • Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                  – Brad Wilson
                                  Oct 18 '08 at 17:17











                                • 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
                                  Oct 18 '08 at 19:23











                                • 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
                                  Oct 18 '08 at 19:51






                                • 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
                                  Dec 3 '11 at 16:41














                                179












                                179








                                179







                                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






                                share|improve this answer















                                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







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Nov 19 '11 at 9:37


























                                community wiki





                                2 revs, 2 users 80%
                                TheSoftwareJedi















                                • 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
                                  Oct 18 '08 at 17:02











                                • Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                  – Brad Wilson
                                  Oct 18 '08 at 17:17











                                • 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
                                  Oct 18 '08 at 19:23











                                • 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
                                  Oct 18 '08 at 19:51






                                • 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
                                  Dec 3 '11 at 16:41



















                                • 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
                                  Oct 18 '08 at 17:02











                                • Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                  – Brad Wilson
                                  Oct 18 '08 at 17:17











                                • 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
                                  Oct 18 '08 at 19:23











                                • 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
                                  Oct 18 '08 at 19:51






                                • 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
                                  Dec 3 '11 at 16:41

















                                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
                                Oct 18 '08 at 17:02





                                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
                                Oct 18 '08 at 17:02













                                Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                – Brad Wilson
                                Oct 18 '08 at 17:17





                                Clearly, whether you use S or s it will have caused this questions, so down-vote Richter. ;)

                                – Brad Wilson
                                Oct 18 '08 at 17:17













                                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
                                Oct 18 '08 at 19:23





                                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
                                Oct 18 '08 at 19:23













                                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
                                Oct 18 '08 at 19:51





                                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
                                Oct 18 '08 at 19:51




                                7




                                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
                                Dec 3 '11 at 16:41





                                "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
                                Dec 3 '11 at 16:41











                                166














                                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.






                                share|improve this answer





















                                • 1





                                  string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                  – CesarGon
                                  Jul 31 '11 at 17:58











                                • @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
                                  Jul 31 '11 at 19:03






                                • 9





                                  According 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
                                  Jul 31 '11 at 19:30













                                • 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
                                  Jul 8 '13 at 16:50
















                                166














                                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.






                                share|improve this answer





















                                • 1





                                  string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                  – CesarGon
                                  Jul 31 '11 at 17:58











                                • @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
                                  Jul 31 '11 at 19:03






                                • 9





                                  According 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
                                  Jul 31 '11 at 19:30













                                • 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
                                  Jul 8 '13 at 16:50














                                166












                                166








                                166







                                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.






                                share|improve this answer















                                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.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Dec 25 '15 at 12:55


























                                community wiki





                                3 revs, 2 users 81%
                                Rasmus Faber









                                • 1





                                  string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                  – CesarGon
                                  Jul 31 '11 at 17:58











                                • @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
                                  Jul 31 '11 at 19:03






                                • 9





                                  According 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
                                  Jul 31 '11 at 19:30













                                • 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
                                  Jul 8 '13 at 16:50














                                • 1





                                  string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                  – CesarGon
                                  Jul 31 '11 at 17:58











                                • @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
                                  Jul 31 '11 at 19:03






                                • 9





                                  According 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
                                  Jul 31 '11 at 19:30













                                • 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
                                  Jul 8 '13 at 16:50








                                1




                                1





                                string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                – CesarGon
                                Jul 31 '11 at 17:58





                                string is not a type in C#; it is a reserved word that maps to a type in the CLR.

                                – CesarGon
                                Jul 31 '11 at 17:58













                                @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
                                Jul 31 '11 at 19:03





                                @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
                                Jul 31 '11 at 19:03




                                9




                                9





                                According 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
                                Jul 31 '11 at 19:30







                                According 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
                                Jul 31 '11 at 19:30















                                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
                                Jul 8 '13 at 16:50





                                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
                                Jul 8 '13 at 16:50











                                153














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





                                share|improve this answer





















                                • 24





                                  "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
                                  Nov 6 '14 at 12:04






                                • 2





                                  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. 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
                                  Nov 4 '16 at 14:11
















                                153














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





                                share|improve this answer





















                                • 24





                                  "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
                                  Nov 6 '14 at 12:04






                                • 2





                                  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. 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
                                  Nov 4 '16 at 14:11














                                153












                                153








                                153







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





                                share|improve this answer















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






                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Feb 28 '15 at 10:48


























                                community wiki





                                3 revs, 3 users 85%
                                Shivprasad Koirala









                                • 24





                                  "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
                                  Nov 6 '14 at 12:04






                                • 2





                                  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. 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
                                  Nov 4 '16 at 14:11














                                • 24





                                  "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
                                  Nov 6 '14 at 12:04






                                • 2





                                  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. 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
                                  Nov 4 '16 at 14:11








                                24




                                24





                                "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
                                Nov 6 '14 at 12:04





                                "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
                                Nov 6 '14 at 12:04




                                2




                                2





                                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. 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
                                Nov 4 '16 at 14:11





                                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. 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
                                Nov 4 '16 at 14:11











                                142














                                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.






                                share|improve this answer


























                                • You don't need to prefix System to use String.

                                  – Joe Ratzer
                                  Oct 18 '08 at 19:24






                                • 17





                                  You 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
                                  Oct 16 '09 at 17:53
















                                142














                                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.






                                share|improve this answer


























                                • You don't need to prefix System to use String.

                                  – Joe Ratzer
                                  Oct 18 '08 at 19:24






                                • 17





                                  You 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
                                  Oct 16 '09 at 17:53














                                142












                                142








                                142







                                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.






                                share|improve this answer















                                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.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Dec 3 '11 at 19:53


























                                community wiki





                                4 revs, 3 users 63%
                                Hallgrim















                                • You don't need to prefix System to use String.

                                  – Joe Ratzer
                                  Oct 18 '08 at 19:24






                                • 17





                                  You 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
                                  Oct 16 '09 at 17:53



















                                • You don't need to prefix System to use String.

                                  – Joe Ratzer
                                  Oct 18 '08 at 19:24






                                • 17





                                  You 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
                                  Oct 16 '09 at 17:53

















                                You don't need to prefix System to use String.

                                – Joe Ratzer
                                Oct 18 '08 at 19:24





                                You don't need to prefix System to use String.

                                – Joe Ratzer
                                Oct 18 '08 at 19:24




                                17




                                17





                                You 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
                                Oct 16 '09 at 17:53





                                You 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
                                Oct 16 '09 at 17:53











                                142














                                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.






                                share|improve this answer





















                                • 4





                                  That'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
                                  May 29 '15 at 20:23








                                • 10





                                  not 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
                                  Feb 24 '16 at 6:57
















                                142














                                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.






                                share|improve this answer





















                                • 4





                                  That'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
                                  May 29 '15 at 20:23








                                • 10





                                  not 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
                                  Feb 24 '16 at 6:57














                                142












                                142








                                142







                                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.






                                share|improve this answer















                                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.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Aug 14 '17 at 4:33


























                                community wiki





                                3 revs, 3 users 60%
                                urini









                                • 4





                                  That'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
                                  May 29 '15 at 20:23








                                • 10





                                  not 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
                                  Feb 24 '16 at 6:57














                                • 4





                                  That'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
                                  May 29 '15 at 20:23








                                • 10





                                  not 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
                                  Feb 24 '16 at 6:57








                                4




                                4





                                That'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
                                May 29 '15 at 20:23







                                That'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
                                May 29 '15 at 20:23






                                10




                                10





                                not 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
                                Feb 24 '16 at 6:57





                                not 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
                                Feb 24 '16 at 6:57











                                128














                                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






                                share|improve this answer






























                                  128














                                  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






                                  share|improve this answer




























                                    128












                                    128








                                    128







                                    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






                                    share|improve this answer















                                    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







                                    share|improve this answer














                                    share|improve this answer



                                    share|improve this answer








                                    edited Aug 14 '17 at 5:16


























                                    community wiki





                                    2 revs, 2 users 80%
                                    Pradeep Kumar Mishra
























                                        108














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






                                        share|improve this answer





















                                        • 4





                                          I 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
                                          May 5 '11 at 18:41
















                                        108














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






                                        share|improve this answer





















                                        • 4





                                          I 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
                                          May 5 '11 at 18:41














                                        108












                                        108








                                        108







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






                                        share|improve this answer















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







                                        share|improve this answer














                                        share|improve this answer



                                        share|improve this answer








                                        edited Nov 19 '11 at 9:35


























                                        community wiki





                                        2 revs, 2 users 67%
                                        Lloyd Cotten










                                        • 4





                                          I 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
                                          May 5 '11 at 18:41














                                        • 4





                                          I 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
                                          May 5 '11 at 18:41








                                        4




                                        4





                                        I 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
                                        May 5 '11 at 18:41





                                        I 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
                                        May 5 '11 at 18:41











                                        88














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






                                        share|improve this answer





















                                        • 1





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

                                          – grant
                                          Jul 1 '11 at 20:35
















                                        88














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






                                        share|improve this answer





















                                        • 1





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

                                          – grant
                                          Jul 1 '11 at 20:35














                                        88












                                        88








                                        88







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






                                        share|improve this answer















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







                                        share|improve this answer














                                        share|improve this answer



                                        share|improve this answer








                                        answered Sep 22 '08 at 19:40


























                                        community wiki





                                        Ishmael









                                        • 1





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

                                          – grant
                                          Jul 1 '11 at 20:35














                                        • 1





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

                                          – grant
                                          Jul 1 '11 at 20:35








                                        1




                                        1





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

                                        – grant
                                        Jul 1 '11 at 20:35





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

                                        – grant
                                        Jul 1 '11 at 20:35











                                        82














                                        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.






                                        share|improve this answer






























                                          82














                                          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.






                                          share|improve this answer




























                                            82












                                            82








                                            82







                                            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.






                                            share|improve this answer















                                            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.







                                            share|improve this answer














                                            share|improve this answer



                                            share|improve this answer








                                            edited Nov 19 '11 at 9:35


























                                            community wiki





                                            2 revs, 2 users 67%
                                            RolandK

























                                                77














                                                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.






                                                share|improve this answer






























                                                  77














                                                  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.






                                                  share|improve this answer




























                                                    77












                                                    77








                                                    77







                                                    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.






                                                    share|improve this answer















                                                    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.







                                                    share|improve this answer














                                                    share|improve this answer



                                                    share|improve this answer








                                                    edited Oct 8 '16 at 18:50


























                                                    community wiki





                                                    4 revs, 3 users 78%
                                                    JeeShen Lee
























                                                        69














                                                        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.






                                                        share|improve this answer






























                                                          69














                                                          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.






                                                          share|improve this answer




























                                                            69












                                                            69








                                                            69







                                                            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.






                                                            share|improve this answer















                                                            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.







                                                            share|improve this answer














                                                            share|improve this answer



                                                            share|improve this answer








                                                            edited Dec 24 '13 at 4:50


























                                                            community wiki





                                                            2 revs, 2 users 67%
                                                            Joe Alfano
























                                                                67














                                                                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’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. Similarly,
                                                                  I’ve heard some developers say that int represents a 32-bit integer when the application
                                                                  is running on a 32-bit OS and that it represents a 64-bit integer when the application
                                                                  is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
                                                                  to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
                                                                  code is running on. If programmers would use Int32 in their code, then this potential
                                                                  confusion is also eliminated.


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


                                                                • Many programmers that use C# exclusively tend to forget that other programming
                                                                  languages can be used against the CLR, and because of this, C#-isms creep into the
                                                                  class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
                                                                  developers on the FCL team have now introduced methods into the library such as
                                                                  Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
                                                                  in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
                                                                  LongCount method.





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






                                                                share|improve this answer






























                                                                  67














                                                                  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’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. Similarly,
                                                                    I’ve heard some developers say that int represents a 32-bit integer when the application
                                                                    is running on a 32-bit OS and that it represents a 64-bit integer when the application
                                                                    is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
                                                                    to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
                                                                    code is running on. If programmers would use Int32 in their code, then this potential
                                                                    confusion is also eliminated.


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


                                                                  • Many programmers that use C# exclusively tend to forget that other programming
                                                                    languages can be used against the CLR, and because of this, C#-isms creep into the
                                                                    class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
                                                                    developers on the FCL team have now introduced methods into the library such as
                                                                    Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
                                                                    in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
                                                                    LongCount method.





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






                                                                  share|improve this answer




























                                                                    67












                                                                    67








                                                                    67







                                                                    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’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. Similarly,
                                                                      I’ve heard some developers say that int represents a 32-bit integer when the application
                                                                      is running on a 32-bit OS and that it represents a 64-bit integer when the application
                                                                      is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
                                                                      to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
                                                                      code is running on. If programmers would use Int32 in their code, then this potential
                                                                      confusion is also eliminated.


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


                                                                    • Many programmers that use C# exclusively tend to forget that other programming
                                                                      languages can be used against the CLR, and because of this, C#-isms creep into the
                                                                      class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
                                                                      developers on the FCL team have now introduced methods into the library such as
                                                                      Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
                                                                      in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
                                                                      LongCount method.





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






                                                                    share|improve this answer















                                                                    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’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. Similarly,
                                                                      I’ve heard some developers say that int represents a 32-bit integer when the application
                                                                      is running on a 32-bit OS and that it represents a 64-bit integer when the application
                                                                      is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
                                                                      to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
                                                                      code is running on. If programmers would use Int32 in their code, then this potential
                                                                      confusion is also eliminated.


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


                                                                    • Many programmers that use C# exclusively tend to forget that other programming
                                                                      languages can be used against the CLR, and because of this, C#-isms creep into the
                                                                      class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
                                                                      developers on the FCL team have now introduced methods into the library such as
                                                                      Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
                                                                      in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
                                                                      LongCount method.





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







                                                                    share|improve this answer














                                                                    share|improve this answer



                                                                    share|improve this answer








                                                                    edited Dec 5 '18 at 9:34


























                                                                    community wiki





                                                                    2 revs, 2 users 58%
                                                                    Otiel
























                                                                        63














                                                                        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.






                                                                        share|improve this answer






























                                                                          63














                                                                          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.






                                                                          share|improve this answer




























                                                                            63












                                                                            63








                                                                            63







                                                                            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.






                                                                            share|improve this answer















                                                                            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.







                                                                            share|improve this answer














                                                                            share|improve this answer



                                                                            share|improve this answer








                                                                            edited Nov 19 '11 at 9:35


























                                                                            community wiki





                                                                            2 revs, 2 users 67%
                                                                            user576533

























                                                                                63














                                                                                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.






                                                                                share|improve this answer


























                                                                                • Thank you for your life history

                                                                                  – user4350912
                                                                                  May 17 '18 at 8:40
















                                                                                63














                                                                                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.






                                                                                share|improve this answer


























                                                                                • Thank you for your life history

                                                                                  – user4350912
                                                                                  May 17 '18 at 8:40














                                                                                63












                                                                                63








                                                                                63







                                                                                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.






                                                                                share|improve this answer















                                                                                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.







                                                                                share|improve this answer














                                                                                share|improve this answer



                                                                                share|improve this answer








                                                                                answered Aug 24 '12 at 15:22


























                                                                                community wiki





                                                                                Michael Ray Lovett














                                                                                • Thank you for your life history

                                                                                  – user4350912
                                                                                  May 17 '18 at 8:40



















                                                                                • Thank you for your life history

                                                                                  – user4350912
                                                                                  May 17 '18 at 8:40

















                                                                                Thank you for your life history

                                                                                – user4350912
                                                                                May 17 '18 at 8:40





                                                                                Thank you for your life history

                                                                                – user4350912
                                                                                May 17 '18 at 8:40











                                                                                57














                                                                                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.






                                                                                share|improve this answer






























                                                                                  57














                                                                                  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.






                                                                                  share|improve this answer




























                                                                                    57












                                                                                    57








                                                                                    57







                                                                                    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.






                                                                                    share|improve this answer















                                                                                    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.







                                                                                    share|improve this answer














                                                                                    share|improve this answer



                                                                                    share|improve this answer








                                                                                    edited Oct 3 '18 at 4:24


























                                                                                    community wiki





                                                                                    2 revs, 2 users 67%
                                                                                    Mel
























                                                                                        48














                                                                                        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.






                                                                                        share|improve this answer


























                                                                                        • In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                          – Alex
                                                                                          Jul 25 '12 at 15:26






                                                                                        • 1





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

                                                                                          – flindeberg
                                                                                          Apr 17 '13 at 7:18






                                                                                        • 1





                                                                                          IntPtr 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
                                                                                          Apr 23 '13 at 21:20






                                                                                        • 1





                                                                                          stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                          – Craig
                                                                                          May 23 '13 at 22:37
















                                                                                        48














                                                                                        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.






                                                                                        share|improve this answer


























                                                                                        • In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                          – Alex
                                                                                          Jul 25 '12 at 15:26






                                                                                        • 1





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

                                                                                          – flindeberg
                                                                                          Apr 17 '13 at 7:18






                                                                                        • 1





                                                                                          IntPtr 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
                                                                                          Apr 23 '13 at 21:20






                                                                                        • 1





                                                                                          stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                          – Craig
                                                                                          May 23 '13 at 22:37














                                                                                        48












                                                                                        48








                                                                                        48







                                                                                        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.






                                                                                        share|improve this answer















                                                                                        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.







                                                                                        share|improve this answer














                                                                                        share|improve this answer



                                                                                        share|improve this answer








                                                                                        edited Jan 15 '12 at 0:30


























                                                                                        community wiki





                                                                                        2 revs, 2 users 89%
                                                                                        Oded















                                                                                        • In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                          – Alex
                                                                                          Jul 25 '12 at 15:26






                                                                                        • 1





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

                                                                                          – flindeberg
                                                                                          Apr 17 '13 at 7:18






                                                                                        • 1





                                                                                          IntPtr 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
                                                                                          Apr 23 '13 at 21:20






                                                                                        • 1





                                                                                          stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                          – Craig
                                                                                          May 23 '13 at 22:37



















                                                                                        • In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                          – Alex
                                                                                          Jul 25 '12 at 15:26






                                                                                        • 1





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

                                                                                          – flindeberg
                                                                                          Apr 17 '13 at 7:18






                                                                                        • 1





                                                                                          IntPtr 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
                                                                                          Apr 23 '13 at 21:20






                                                                                        • 1





                                                                                          stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                          – Craig
                                                                                          May 23 '13 at 22:37

















                                                                                        In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                        – Alex
                                                                                        Jul 25 '12 at 15:26





                                                                                        In a 64 bit build, int maps to System.Int64 (8 bytes) , in 32 bit build it maps to System.Int32 (4 bytes)

                                                                                        – Alex
                                                                                        Jul 25 '12 at 15:26




                                                                                        1




                                                                                        1





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

                                                                                        – flindeberg
                                                                                        Apr 17 '13 at 7:18





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

                                                                                        – flindeberg
                                                                                        Apr 17 '13 at 7:18




                                                                                        1




                                                                                        1





                                                                                        IntPtr 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
                                                                                        Apr 23 '13 at 21:20





                                                                                        IntPtr 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
                                                                                        Apr 23 '13 at 21:20




                                                                                        1




                                                                                        1





                                                                                        stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                        – Craig
                                                                                        May 23 '13 at 22:37





                                                                                        stackoverflow.com/questions/651956/sizeofint-on-x64

                                                                                        – Craig
                                                                                        May 23 '13 at 22:37











                                                                                        46














                                                                                        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.






                                                                                        share|improve this answer





















                                                                                        • 4





                                                                                          I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                          – Steve
                                                                                          May 8 '15 at 0:40








                                                                                        • 1





                                                                                          this is the right answer. string is System.String. String could be anything.

                                                                                          – Dave Cousineau
                                                                                          Oct 9 '18 at 20:26
















                                                                                        46














                                                                                        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.






                                                                                        share|improve this answer





















                                                                                        • 4





                                                                                          I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                          – Steve
                                                                                          May 8 '15 at 0:40








                                                                                        • 1





                                                                                          this is the right answer. string is System.String. String could be anything.

                                                                                          – Dave Cousineau
                                                                                          Oct 9 '18 at 20:26














                                                                                        46












                                                                                        46








                                                                                        46







                                                                                        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.






                                                                                        share|improve this answer















                                                                                        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.







                                                                                        share|improve this answer














                                                                                        share|improve this answer



                                                                                        share|improve this answer








                                                                                        answered Jan 15 '15 at 14:21


























                                                                                        community wiki





                                                                                        Jeppe Stig Nielsen









                                                                                        • 4





                                                                                          I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                          – Steve
                                                                                          May 8 '15 at 0:40








                                                                                        • 1





                                                                                          this is the right answer. string is System.String. String could be anything.

                                                                                          – Dave Cousineau
                                                                                          Oct 9 '18 at 20:26














                                                                                        • 4





                                                                                          I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                          – Steve
                                                                                          May 8 '15 at 0:40








                                                                                        • 1





                                                                                          this is the right answer. string is System.String. String could be anything.

                                                                                          – Dave Cousineau
                                                                                          Oct 9 '18 at 20:26








                                                                                        4




                                                                                        4





                                                                                        I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                        – Steve
                                                                                        May 8 '15 at 0:40







                                                                                        I suppose to be diabolical one could: using String = System.Int32; using Int32 = System.String; and then count the bugs.

                                                                                        – Steve
                                                                                        May 8 '15 at 0:40






                                                                                        1




                                                                                        1





                                                                                        this is the right answer. string is System.String. String could be anything.

                                                                                        – Dave Cousineau
                                                                                        Oct 9 '18 at 20:26





                                                                                        this is the right answer. string is System.String. String could be anything.

                                                                                        – Dave Cousineau
                                                                                        Oct 9 '18 at 20:26











                                                                                        41














                                                                                        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.







                                                                                        share|improve this answer






























                                                                                          41














                                                                                          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.







                                                                                          share|improve this answer




























                                                                                            41












                                                                                            41








                                                                                            41







                                                                                            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.







                                                                                            share|improve this answer















                                                                                            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.








                                                                                            share|improve this answer














                                                                                            share|improve this answer



                                                                                            share|improve this answer








                                                                                            edited Dec 11 '16 at 5:27


























                                                                                            community wiki





                                                                                            3 revs, 3 users 67%
                                                                                            user2771704
























                                                                                                40














                                                                                                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)





                                                                                                share|improve this answer





















                                                                                                • 1





                                                                                                  The 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
                                                                                                  Mar 4 '18 at 9:29
















                                                                                                40














                                                                                                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)





                                                                                                share|improve this answer





















                                                                                                • 1





                                                                                                  The 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
                                                                                                  Mar 4 '18 at 9:29














                                                                                                40












                                                                                                40








                                                                                                40







                                                                                                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)





                                                                                                share|improve this answer















                                                                                                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)






                                                                                                share|improve this answer














                                                                                                share|improve this answer



                                                                                                share|improve this answer








                                                                                                edited Mar 16 '16 at 19:35


























                                                                                                community wiki





                                                                                                2 revs, 2 users 73%
                                                                                                CoreDeveloper









                                                                                                • 1





                                                                                                  The 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
                                                                                                  Mar 4 '18 at 9:29














                                                                                                • 1





                                                                                                  The 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
                                                                                                  Mar 4 '18 at 9:29








                                                                                                1




                                                                                                1





                                                                                                The 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
                                                                                                Mar 4 '18 at 9:29





                                                                                                The 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
                                                                                                Mar 4 '18 at 9:29











                                                                                                38














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






                                                                                                share|improve this answer






























                                                                                                  38














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






                                                                                                  share|improve this answer




























                                                                                                    38












                                                                                                    38








                                                                                                    38







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






                                                                                                    share|improve this answer















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







                                                                                                    share|improve this answer














                                                                                                    share|improve this answer



                                                                                                    share|improve this answer








                                                                                                    edited Dec 25 '15 at 12:55


























                                                                                                    community wiki





                                                                                                    2 revs, 2 users 67%
                                                                                                    Coder
























                                                                                                        33














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






                                                                                                        share|improve this answer






























                                                                                                          33














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






                                                                                                          share|improve this answer




























                                                                                                            33












                                                                                                            33








                                                                                                            33







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






                                                                                                            share|improve this answer















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







                                                                                                            share|improve this answer














                                                                                                            share|improve this answer



                                                                                                            share|improve this answer








                                                                                                            edited Nov 19 '11 at 9:34


























                                                                                                            community wiki





                                                                                                            2 revs, 2 users 67%
                                                                                                            Dot NET
























                                                                                                                1 2
                                                                                                                next




                                                                                                                protected by Community Apr 22 '12 at 14:57



                                                                                                                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?



                                                                                                                Popular posts from this blog

                                                                                                                Monofisismo

                                                                                                                Angular Downloading a file using contenturl with Basic Authentication

                                                                                                                Olmecas