String or string?
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
I also prefer the differentiation, and I know other Code Projectors have said the same thing. I dislike the aliases and I'd rather they weren't built in -- let the user define them as required. What I find crazy is that when specifying the underlying type for an enumeration, you must use the alias. X| And think I recall that there's a place where you mustn't use the alias.
-
I used to think that String referred to a class, whereas string was just a simple type. I believe at some point in the past this was the case?? However, I now just use the lower case variant for simplicity.
Get me coffee and no one gets hurt!
Cornelius Henning wrote:
I believe at some point in the past this was the case??
Nope, never. It's just an alias.
string
Visual Studio .NET 2003
The string type represents a string of Unicode characters. string is an alias for System.String in the .NET Framework. -
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
I've always used the lowercase string when declaring a type, but I use the uppercase String when calling static methods. For example:
string myString = "Hello World!";
string anotherString = String.Format("{0}", "Hola!");Microsoft seems to do the same thing, as seen in some of their examples, like here.
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
Now that you have made up your mind, let me generate some doubts again. It's no secret that value types don't really exist. They are classes, reference types, that are made to behave like value types by the compiler. You can use tham as reference types if you wish by working with the classes. If you want the value type behavior, you use the alias and the compiler does the rest. The question which one to use is less a question of style. It's more a question of what you want to accomplish and strictly choosing one or the other limits your options without any real need.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
I also prefer the differentiation, and I know other Code Projectors have said the same thing. I dislike the aliases and I'd rather they weren't built in -- let the user define them as required. What I find crazy is that when specifying the underlying type for an enumeration, you must use the alias. X| And think I recall that there's a place where you mustn't use the alias.
PIEBALDconsult wrote:
What I find crazy is that when specifying the underlying type for an enumeration, you must use the alias. X|
Not if you're using the Roslyn (C# 6 / VS2015) compiler:
enum Foo : Int32
{
Bar,
Baz,
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I used to think that String referred to a class, whereas string was just a simple type. I believe at some point in the past this was the case?? However, I now just use the lower case variant for simplicity.
Get me coffee and no one gets hurt!
Could it be that you are confusing this with Java? .Net never had primitive types. One of the most important differences when the Java guys still dismissed c# as a bad copy of Java.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Now that you have made up your mind, let me generate some doubts again. It's no secret that value types don't really exist. They are classes, reference types, that are made to behave like value types by the compiler. You can use tham as reference types if you wish by working with the classes. If you want the value type behavior, you use the alias and the compiler does the rest. The question which one to use is less a question of style. It's more a question of what you want to accomplish and strictly choosing one or the other limits your options without any real need.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.Are you sure you're not thinking of Java? :confused: With .NET, there's no difference in behaviour between using the class name or the alias.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I also prefer the differentiation, and I know other Code Projectors have said the same thing. I dislike the aliases and I'd rather they weren't built in -- let the user define them as required. What I find crazy is that when specifying the underlying type for an enumeration, you must use the alias. X| And think I recall that there's a place where you mustn't use the alias.
There is a tiny difference, remember? Classes are reference types while the aliases are made to appear like value types for convenience.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Now that you have made up your mind, let me generate some doubts again. It's no secret that value types don't really exist. They are classes, reference types, that are made to behave like value types by the compiler. You can use tham as reference types if you wish by working with the classes. If you want the value type behavior, you use the alias and the compiler does the rest. The question which one to use is less a question of style. It's more a question of what you want to accomplish and strictly choosing one or the other limits your options without any real need.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.Value types fundamentally act differently in MSIL as well so it's not just a cheat. `int` is a real value type, it's even (along with most built-in types) extra special in the sense that it's built into MSIL directly. `Int32` is not a reference type either. String is a reference type, but so is string, it's just not very noticeable since it's mostly immutable.
-
Are you sure you're not thinking of Java? :confused: With .NET, there's no difference in behaviour between using the class name or the alias.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Don't think so, when was the last time you had to initialize an int with new() before using it or check for null? Now try that with Int32, which without question is the class that corresponds to int.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Don't think so, when was the last time you had to initialize an int with new() before using it or check for null? Now try that with Int32, which without question is the class that corresponds to int.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.You mean like [this](http://ideone.com/zmqvAx) ?
-
There is a tiny difference, remember? Classes are reference types while the aliases are made to appear like value types for convenience.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Could it be that you are confusing this with Java? .Net never had primitive types. One of the most important differences when the Java guys still dismissed c# as a bad copy of Java.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Cornelius Henning wrote:
I believe at some point in the past this was the case??
Nope, never. It's just an alias.
string
Visual Studio .NET 2003
The string type represents a string of Unicode characters. string is an alias for System.String in the .NET Framework. -
Are you sure you're not thinking of Java? :confused: With .NET, there's no difference in behaviour between using the class name or the alias.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Value types fundamentally act differently in MSIL as well so it's not just a cheat. `int` is a real value type, it's even (along with most built-in types) extra special in the sense that it's built into MSIL directly. `Int32` is not a reference type either. String is a reference type, but so is string, it's just not very noticeable since it's mostly immutable.
Now it gets confusing. The MSDN does not mention any of this at first glance for the String class. They use string in their samples when they want to use it as a value type and describe how initializing a string with a literal leads to the generation of code that uses one of String's constructors in MISL.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Now it gets confusing. The MSDN does not mention any of this at first glance for the String class. They use string in their samples when they want to use it as a value type and describe how initializing a string with a literal leads to the generation of code that uses one of String's constructors in MISL.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.Well it's built-in, so it's always going to be a bit odd. Still, you can tell it's not a value type by [cheating](http://ideone.com/v9xjcG), if it was actually a value type it should be impossible to change the original, but as this experiment shows it is only made "impossible" by the immutability.