What is the difference between String and string in C#?
Example (note the case):
string s = "Hello world!";
String s = "Hello world!";
What are the guidelines for the use of each? And what are the differences?
c# .net string types alias
|
show 5 more comments
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
45
@O.R.Mapper, but the fact remains thatstring
is a lexical construct of the C# grammar whereasSystem.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 supportstring
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 considerstring
to be exactly the same as the BCL typeSystem.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 usestring
without a using directive for System. You can't do that withString
.
– Wilsu
Nov 30 '15 at 8:52
7
For someone coming from Algol and Fortran, this discussion shows there is something wrong withstring
. It is needed to abbreviateSystem.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 usestring
andstring.Format()
and not to worry aboutSystem.String
.
– Roland
Dec 20 '16 at 0:24
2
@Sangeeta What are you saying? TheSystem.String
class is still there, and thestring
keyword is still an alias for it. Just likeSystem.Int32
andint
. They are literally the same thing.
– Craig
Dec 8 '18 at 2:14
|
show 5 more comments
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
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
c# .net string types alias
edited Jun 27 '18 at 16:42
community wiki
23 revs, 19 users 12%
Peter O.
45
@O.R.Mapper, but the fact remains thatstring
is a lexical construct of the C# grammar whereasSystem.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 supportstring
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 considerstring
to be exactly the same as the BCL typeSystem.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 usestring
without a using directive for System. You can't do that withString
.
– Wilsu
Nov 30 '15 at 8:52
7
For someone coming from Algol and Fortran, this discussion shows there is something wrong withstring
. It is needed to abbreviateSystem.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 usestring
andstring.Format()
and not to worry aboutSystem.String
.
– Roland
Dec 20 '16 at 0:24
2
@Sangeeta What are you saying? TheSystem.String
class is still there, and thestring
keyword is still an alias for it. Just likeSystem.Int32
andint
. They are literally the same thing.
– Craig
Dec 8 '18 at 2:14
|
show 5 more comments
45
@O.R.Mapper, but the fact remains thatstring
is a lexical construct of the C# grammar whereasSystem.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 supportstring
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 considerstring
to be exactly the same as the BCL typeSystem.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 usestring
without a using directive for System. You can't do that withString
.
– Wilsu
Nov 30 '15 at 8:52
7
For someone coming from Algol and Fortran, this discussion shows there is something wrong withstring
. It is needed to abbreviateSystem.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 usestring
andstring.Format()
and not to worry aboutSystem.String
.
– Roland
Dec 20 '16 at 0:24
2
@Sangeeta What are you saying? TheSystem.String
class is still there, and thestring
keyword is still an alias for it. Just likeSystem.Int32
andint
. 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
|
show 5 more comments
57 Answers
57
active
oldest
votes
1 2
next
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.
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 forstring.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 whereasnameof(String)
will.
– Jeroen Vannevel
Feb 5 '16 at 20:38
|
show 25 more comments
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.
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 betweenstring
andString
is thatstring' 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, asString
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 asstring
though. It's a sort of escaping mechanism.
– Jon Skeet
Jun 5 '13 at 7:18
|
show 17 more comments
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..
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 thatint
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. Changingint
to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefininglong
, aslong
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 usingInt16
,Int32
andInt64
is a lot more transparent in the code than using the rather nondescriptiveshort
,int
andlong
– Nyerguds
Dec 9 '18 at 2:29
add a comment |
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.
15
The second point sounds actually like a reason not to usestring
,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 whichlong
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
|
show 3 more comments
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.
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
|
show 2 more comments
There is one difference - you can't use String
without using System;
beforehand.
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 onlyusing
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 tointernal 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
add a comment |
It's been covered above; however, you can't use string
in reflection; you must use String
.
add a comment |
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.
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 useshort
,int
,ushort
,uint
instead ofInt16
, etc. Mostly because this is how I learned. Granted, theInt16
is easier to immediately understand for those with less experience. +1 From me!
– PerpetualJ
Jan 2 at 19:18
add a comment |
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;
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 useInt32 i=1;
intstead ofint 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 usevar
– tic
Mar 18 '16 at 15:38
|
show 3 more comments
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
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
|
show 1 more comment
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.
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
add a comment |
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.
"System.String
" a.k.a "String" ( capital "S") is a .NET
framework data type while "string" is a C#
data type.
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() ;
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 writeString
it suggest you to "simplify your code", carrying it tostring
...
– Massimiliano Kraus
Nov 4 '16 at 14:11
add a comment |
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
.
You don't need to prefix System to use String.
– Joe Ratzer
Oct 18 '08 at 19:24
17
You do have to include ausing System
when usingString
, 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
add a comment |
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.
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
add a comment |
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
add a comment |
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...
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
add a comment |
Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
Thank you for your life history
– user4350912
May 17 '18 at 8:40
add a comment |
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.
add a comment |
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
.
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 likeint*
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
add a comment |
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 using
s) 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.
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
isSystem.String
.String
could be anything.
– Dave Cousineau
Oct 9 '18 at 20:26
add a comment |
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.
add a comment |
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)
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
add a comment |
Yes, that's no difference between them, just like the bool
and Boolean
.
add a comment |
There is no difference between the two - string
, however, appears to be the preferred option when considering other developers' source code.
add a comment |
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
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.
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 forstring.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 whereasnameof(String)
will.
– Jeroen Vannevel
Feb 5 '16 at 20:38
|
show 25 more comments
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.
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 forstring.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 whereasnameof(String)
will.
– Jeroen Vannevel
Feb 5 '16 at 20:38
|
show 25 more comments
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.
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.
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 forstring.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 whereasnameof(String)
will.
– Jeroen Vannevel
Feb 5 '16 at 20:38
|
show 25 more comments
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 forstring.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 whereasnameof(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
|
show 25 more comments
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.
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 betweenstring
andString
is thatstring' 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, asString
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 asstring
though. It's a sort of escaping mechanism.
– Jon Skeet
Jun 5 '13 at 7:18
|
show 17 more comments
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.
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 betweenstring
andString
is thatstring' 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, asString
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 asstring
though. It's a sort of escaping mechanism.
– Jon Skeet
Jun 5 '13 at 7:18
|
show 17 more comments
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.
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.
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 betweenstring
andString
is thatstring' 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, asString
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 asstring
though. It's a sort of escaping mechanism.
– Jon Skeet
Jun 5 '13 at 7:18
|
show 17 more comments
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 betweenstring
andString
is thatstring' 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, asString
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 asstring
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
|
show 17 more comments
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..
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 thatint
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. Changingint
to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefininglong
, aslong
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 usingInt16
,Int32
andInt64
is a lot more transparent in the code than using the rather nondescriptiveshort
,int
andlong
– Nyerguds
Dec 9 '18 at 2:29
add a comment |
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..
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 thatint
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. Changingint
to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefininglong
, aslong
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 usingInt16
,Int32
andInt64
is a lot more transparent in the code than using the rather nondescriptiveshort
,int
andlong
– Nyerguds
Dec 9 '18 at 2:29
add a comment |
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..
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..
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 thatint
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. Changingint
to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefininglong
, aslong
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 usingInt16
,Int32
andInt64
is a lot more transparent in the code than using the rather nondescriptiveshort
,int
andlong
– Nyerguds
Dec 9 '18 at 2:29
add a comment |
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 thatint
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. Changingint
to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefininglong
, aslong
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 usingInt16
,Int32
andInt64
is a lot more transparent in the code than using the rather nondescriptiveshort
,int
andlong
– 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
add a comment |
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.
15
The second point sounds actually like a reason not to usestring
,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 whichlong
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
|
show 3 more comments
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.
15
The second point sounds actually like a reason not to usestring
,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 whichlong
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
|
show 3 more comments
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.
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.
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 usestring
,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 whichlong
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
|
show 3 more comments
15
The second point sounds actually like a reason not to usestring
,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 whichlong
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
|
show 3 more comments
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.
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
|
show 2 more comments
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.
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
|
show 2 more comments
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.
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.
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
|
show 2 more comments
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
|
show 2 more comments
There is one difference - you can't use String
without using System;
beforehand.
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 onlyusing
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 tointernal 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
add a comment |
There is one difference - you can't use String
without using System;
beforehand.
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 onlyusing
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 tointernal 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
add a comment |
There is one difference - you can't use String
without using System;
beforehand.
There is one difference - you can't use String
without using System;
beforehand.
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 onlyusing
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 tointernal 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
add a comment |
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 onlyusing
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 tointernal 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
add a comment |
It's been covered above; however, you can't use string
in reflection; you must use String
.
add a comment |
It's been covered above; however, you can't use string
in reflection; you must use String
.
add a comment |
It's been covered above; however, you can't use string
in reflection; you must use String
.
It's been covered above; however, you can't use string
in reflection; you must use String
.
edited Nov 19 '11 at 9:36
community wiki
2 revs, 2 users 67%
TraumaPony
add a comment |
add a comment |
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.
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 useshort
,int
,ushort
,uint
instead ofInt16
, etc. Mostly because this is how I learned. Granted, theInt16
is easier to immediately understand for those with less experience. +1 From me!
– PerpetualJ
Jan 2 at 19:18
add a comment |
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.
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 useshort
,int
,ushort
,uint
instead ofInt16
, etc. Mostly because this is how I learned. Granted, theInt16
is easier to immediately understand for those with less experience. +1 From me!
– PerpetualJ
Jan 2 at 19:18
add a comment |
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.
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.
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 useshort
,int
,ushort
,uint
instead ofInt16
, etc. Mostly because this is how I learned. Granted, theInt16
is easier to immediately understand for those with less experience. +1 From me!
– PerpetualJ
Jan 2 at 19:18
add a comment |
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 useshort
,int
,ushort
,uint
instead ofInt16
, etc. Mostly because this is how I learned. Granted, theInt16
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
add a comment |
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;
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 useInt32 i=1;
intstead ofint 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 usevar
– tic
Mar 18 '16 at 15:38
|
show 3 more comments
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;
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 useInt32 i=1;
intstead ofint 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 usevar
– tic
Mar 18 '16 at 15:38
|
show 3 more comments
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;
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;
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 useInt32 i=1;
intstead ofint 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 usevar
– tic
Mar 18 '16 at 15:38
|
show 3 more comments
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 useInt32 i=1;
intstead ofint 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 usevar
– 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
|
show 3 more comments
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
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
|
show 1 more comment
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
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
|
show 1 more comment
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
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
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
|
show 1 more comment
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
|
show 1 more comment
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
"System.String
" a.k.a "String" ( capital "S") is a .NET
framework data type while "string" is a C#
data type.
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() ;
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 writeString
it suggest you to "simplify your code", carrying it tostring
...
– Massimiliano Kraus
Nov 4 '16 at 14:11
add a comment |
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.
"System.String
" a.k.a "String" ( capital "S") is a .NET
framework data type while "string" is a C#
data type.
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() ;
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 writeString
it suggest you to "simplify your code", carrying it tostring
...
– Massimiliano Kraus
Nov 4 '16 at 14:11
add a comment |
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.
"System.String
" a.k.a "String" ( capital "S") is a .NET
framework data type while "string" is a C#
data type.
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() ;
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.
"System.String
" a.k.a "String" ( capital "S") is a .NET
framework data type while "string" is a C#
data type.
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() ;
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 writeString
it suggest you to "simplify your code", carrying it tostring
...
– Massimiliano Kraus
Nov 4 '16 at 14:11
add a comment |
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 writeString
it suggest you to "simplify your code", carrying it tostring
...
– 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
add a comment |
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
.
You don't need to prefix System to use String.
– Joe Ratzer
Oct 18 '08 at 19:24
17
You do have to include ausing System
when usingString
, 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
add a comment |
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
.
You don't need to prefix System to use String.
– Joe Ratzer
Oct 18 '08 at 19:24
17
You do have to include ausing System
when usingString
, 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
add a comment |
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
.
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
.
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 ausing System
when usingString
, 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
add a comment |
You don't need to prefix System to use String.
– Joe Ratzer
Oct 18 '08 at 19:24
17
You do have to include ausing System
when usingString
, 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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Aug 14 '17 at 5:16
community wiki
2 revs, 2 users 80%
Pradeep Kumar Mishra
add a comment |
add a comment |
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...
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
add a comment |
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...
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
add a comment |
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...
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...
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
add a comment |
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
add a comment |
Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.
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
add a comment |
Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.
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
add a comment |
Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.
Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 19 '11 at 9:35
community wiki
2 revs, 2 users 67%
RolandK
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
string
is an alias (or shorthand) of System.String
. That means, by typing string
we meant System.String
. You can read more in think link: 'string' is an alias/shorthand of System.String.
string
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.
edited Oct 8 '16 at 18:50
community wiki
4 revs, 3 users 78%
JeeShen Lee
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 24 '13 at 4:50
community wiki
2 revs, 2 users 67%
Joe Alfano
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 5 '18 at 9:34
community wiki
2 revs, 2 users 58%
Otiel
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
String
is not a keyword and it can be used as Identifier whereas string
is a keyword and cannot be used as Identifier. And in function point of view both are same.
String
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.
edited Nov 19 '11 at 9:35
community wiki
2 revs, 2 users 67%
user576533
add a comment |
add a comment |
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.
Thank you for your life history
– user4350912
May 17 '18 at 8:40
add a comment |
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.
Thank you for your life history
– user4350912
May 17 '18 at 8:40
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Oct 3 '18 at 4:24
community wiki
2 revs, 2 users 67%
Mel
add a comment |
add a comment |
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
.
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 likeint*
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
add a comment |
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
.
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 likeint*
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
add a comment |
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
.
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
.
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 likeint*
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
add a comment |
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 likeint*
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
add a comment |
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 using
s) 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.
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
isSystem.String
.String
could be anything.
– Dave Cousineau
Oct 9 '18 at 20:26
add a comment |
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 using
s) 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.
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
isSystem.String
.String
could be anything.
– Dave Cousineau
Oct 9 '18 at 20:26
add a comment |
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 using
s) 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.
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 using
s) 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.
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
isSystem.String
.String
could be anything.
– Dave Cousineau
Oct 9 '18 at 20:26
add a comment |
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
isSystem.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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 11 '16 at 5:27
community wiki
3 revs, 3 users 67%
user2771704
add a comment |
add a comment |
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)
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
add a comment |
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)
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
add a comment |
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)
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)
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
add a comment |
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
add a comment |
Yes, that's no difference between them, just like the bool
and Boolean
.
add a comment |
Yes, that's no difference between them, just like the bool
and Boolean
.
add a comment |
Yes, that's no difference between them, just like the bool
and Boolean
.
Yes, that's no difference between them, just like the bool
and Boolean
.
edited Dec 25 '15 at 12:55
community wiki
2 revs, 2 users 67%
Coder
add a comment |
add a comment |
There is no difference between the two - string
, however, appears to be the preferred option when considering other developers' source code.
add a comment |
There is no difference between the two - string
, however, appears to be the preferred option when considering other developers' source code.
add a comment |
There is no difference between the two - string
, however, appears to be the preferred option when considering other developers' source code.
There is no difference between the two - string
, however, appears to be the preferred option when considering other developers' source code.
edited Nov 19 '11 at 9:34
community wiki
2 revs, 2 users 67%
Dot NET
add a comment |
add a comment |
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?
45
@O.R.Mapper, but the fact remains that
string
is a lexical construct of the C# grammar whereasSystem.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 supportstring
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 typeSystem.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 withString
.– 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 abbreviateSystem.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 usestring
andstring.Format()
and not to worry aboutSystem.String
.– Roland
Dec 20 '16 at 0:24
2
@Sangeeta What are you saying? The
System.String
class is still there, and thestring
keyword is still an alias for it. Just likeSystem.Int32
andint
. They are literally the same thing.– Craig
Dec 8 '18 at 2:14