SA1122 : CSharp.Readability
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
What about
string s = "";
vs
string s = “”;
(yeah, yeah - I know that syntax colouring should make this sligtly obvious, and that the IDE will then underline it all wiggly-like, and then the compiler will barf. But still...) I think the problem here is they are saying it's "readability" when in fact it's more about efficiency and not creating a new object each time.
cheers Chris Maunder
-
What about
string s = "";
vs
string s = “”;
(yeah, yeah - I know that syntax colouring should make this sligtly obvious, and that the IDE will then underline it all wiggly-like, and then the compiler will barf. But still...) I think the problem here is they are saying it's "readability" when in fact it's more about efficiency and not creating a new object each time.
cheers Chris Maunder
Chris Maunder wrote:
What about
That is the only advantage, which is a non-problem if you have a decent font.
Chris Maunder wrote:
I think the problem here is they are saying it's "readability" when in fact it's more about efficiency and not creating a new object each time.
If the motivation is incorrect or nonsense, the rule is ignored. Didn't know that it was a micro-optimisation, as I didn't expect a "new object" for a string-literal. --edit Still thanks for the explanation :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
What about
string s = "";
vs
string s = “”;
(yeah, yeah - I know that syntax colouring should make this sligtly obvious, and that the IDE will then underline it all wiggly-like, and then the compiler will barf. But still...) I think the problem here is they are saying it's "readability" when in fact it's more about efficiency and not creating a new object each time.
cheers Chris Maunder
According to SO: c# - String.Empty versus "" - Stack Overflow[^] the "new object each time" bit might have changed in later versions. And this String.Empty Versus ""[^] would imply that it has indeed been changed. I prefer
string s = "";
anyway - it's just more readable to my mind.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
What about
string s = "";
vs
string s = “”;
(yeah, yeah - I know that syntax colouring should make this sligtly obvious, and that the IDE will then underline it all wiggly-like, and then the compiler will barf. But still...) I think the problem here is they are saying it's "readability" when in fact it's more about efficiency and not creating a new object each time.
cheers Chris Maunder
It doesn't create a new object. String.Empty and "" point to the same spot in memory.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
It doesn't create a new object. String.Empty and "" point to the same spot in memory.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
There is huge advantage of using String.Empty over "" - it has nothing to do with readability...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
No,
string.Emptyis rubbish; you needSystem.String.Empty. As to the issue with""; how does the (uninformed) reader know there aren't any non-printing characters in there? :-D -
No,
string.Emptyis rubbish; you needSystem.String.Empty. As to the issue with""; how does the (uninformed) reader know there aren't any non-printing characters in there? :-DPIEBALDconsult wrote:
No,
string.Emptyis rubbish; you needSystem.String.Empty.Did you mean
global::System.String.Empty?PIEBALDconsult wrote:
As to the issue with
""; how does the (uninformed) reader know there aren't any non-printing characters in there? :-DThe uninformed reader should not come near code and keep to his VB6 code; said reader would also not notice if I'd created another local String-class with a string-member called "Empty" that returns "GET OUT OF MY CODEBASE".
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
There is huge advantage of using String.Empty over "" - it has nothing to do with readability...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
it has nothing to do with readability...
According to StyleCop it is about readability, which it obviously isn't.
Kornfeld Eliyahu Peter wrote:
There is huge advantage of using String.Empty over ""
Yet you do not explain what the advantage might be, where the disadvantages are obvious. ..if there's a yuuge advantage, then I'd like to know. Please, point it out :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
There is no one size fits all and VS code analysis rule set is no exception. If you don't like this particular rule just disable it. Either globally or in place optionally with justification. I actually use string.Empty as it is more readable for me. Shorter code =/= more readable (try only single letter class members...). There are other rules that I find annoying however. Like "GetSomething()" - replace with getter, or "method don't use instance members - use static". Both are cool, except in unit tests. But SuppressMessage attribute handles it nicely there. Overall quality of our code significantly improved when we stared threat CA warnings as errors and reject all pull requests with SupressMessage without Justification. But that is with custom rules as ever evolving company standard :)
-- "My software never has bugs. It just develops random features."
-
Kornfeld Eliyahu Peter wrote:
it has nothing to do with readability...
According to StyleCop it is about readability, which it obviously isn't.
Kornfeld Eliyahu Peter wrote:
There is huge advantage of using String.Empty over ""
Yet you do not explain what the advantage might be, where the disadvantages are obvious. ..if there's a yuuge advantage, then I'd like to know. Please, point it out :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Isn't that obvious?! Using String.Empty will remove that idiotic SA1122! :laugh:
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
There is no one size fits all and VS code analysis rule set is no exception. If you don't like this particular rule just disable it. Either globally or in place optionally with justification. I actually use string.Empty as it is more readable for me. Shorter code =/= more readable (try only single letter class members...). There are other rules that I find annoying however. Like "GetSomething()" - replace with getter, or "method don't use instance members - use static". Both are cool, except in unit tests. But SuppressMessage attribute handles it nicely there. Overall quality of our code significantly improved when we stared threat CA warnings as errors and reject all pull requests with SupressMessage without Justification. But that is with custom rules as ever evolving company standard :)
-- "My software never has bugs. It just develops random features."
Deflinek wrote:
If you don't like this particular rule just disable it.
It is there for a reason, which may or may not be valid, but I do want to know the reasoning behind it. My liking is irrelevant, I want to weigh the implications of both scenario's.
Deflinek wrote:
I actually use string.Empty as it is more readable for me. Shorter code =/= more readable (try only single letter class members...).
No, it is not more readable for you. You might prefer it, but it is not more readable. It takes more symbols to convey the same information, meaning your brain will have to do more validation.
v equalz Onehundredandeighty plus sixtynine
is not more readable than
v = 180 + 69;
That's not even a matter of preference. I do admit that shorter code is not more readable by definition; it does not help if things are obfuscated, but that's hardly the case here, is it? We are simply re-using a long-accepted version of "empty string" (known as such in various languages), instead of calling a (static?) member on an class (which is local to the language, without adding any benefits that are known to me).
Deflinek wrote:
There are other rules that I find annoying however.
It is not that I find it annoying, I'm challenging its validity.
Deflinek wrote:
Overall quality of our code significantly improved when we stared threat CA warnings as errors
No arguing that, every warning is one too many.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Deflinek wrote:
If you don't like this particular rule just disable it.
It is there for a reason, which may or may not be valid, but I do want to know the reasoning behind it. My liking is irrelevant, I want to weigh the implications of both scenario's.
Deflinek wrote:
I actually use string.Empty as it is more readable for me. Shorter code =/= more readable (try only single letter class members...).
No, it is not more readable for you. You might prefer it, but it is not more readable. It takes more symbols to convey the same information, meaning your brain will have to do more validation.
v equalz Onehundredandeighty plus sixtynine
is not more readable than
v = 180 + 69;
That's not even a matter of preference. I do admit that shorter code is not more readable by definition; it does not help if things are obfuscated, but that's hardly the case here, is it? We are simply re-using a long-accepted version of "empty string" (known as such in various languages), instead of calling a (static?) member on an class (which is local to the language, without adding any benefits that are known to me).
Deflinek wrote:
There are other rules that I find annoying however.
It is not that I find it annoying, I'm challenging its validity.
Deflinek wrote:
Overall quality of our code significantly improved when we stared threat CA warnings as errors
No arguing that, every warning is one too many.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
It is there for a reason, which may or may not be valid,
Yes, the reason is to provide a broad set of rules as a template for you to just cut unwanted instead of creating custom ones.
Eddy Vluggen wrote:
No, it is not more readable for you.
I'm glad you know what is/isn't more readable FOR ME.
Eddy Vluggen wrote:
v equalz Onehundredandeighty plus sixtynine
is not more readable than
v = 180 + 69;
Not a good example here. Single letter variable and two magic numbers :) After two months you will scratch your head equally on both lines :)
Eddy Vluggen wrote:
Deflinek wrote:
There are other rules that I find annoying however.
It is not that I find it annoying, I'm challenging its validity.
Again. Those rules are there as a template. The default set probably reflects what their team uses as they had to provide something out of the box. It is better to have a lot of rules that you can customize than have just a few essential ones and write plugins for everything else. And if you don't like this particular one disable it - problem solved.
-- "My software never has bugs. It just develops random features."
-
Eddy Vluggen wrote:
It is there for a reason, which may or may not be valid,
Yes, the reason is to provide a broad set of rules as a template for you to just cut unwanted instead of creating custom ones.
Eddy Vluggen wrote:
No, it is not more readable for you.
I'm glad you know what is/isn't more readable FOR ME.
Eddy Vluggen wrote:
v equalz Onehundredandeighty plus sixtynine
is not more readable than
v = 180 + 69;
Not a good example here. Single letter variable and two magic numbers :) After two months you will scratch your head equally on both lines :)
Eddy Vluggen wrote:
Deflinek wrote:
There are other rules that I find annoying however.
It is not that I find it annoying, I'm challenging its validity.
Again. Those rules are there as a template. The default set probably reflects what their team uses as they had to provide something out of the box. It is better to have a lot of rules that you can customize than have just a few essential ones and write plugins for everything else. And if you don't like this particular one disable it - problem solved.
-- "My software never has bugs. It just develops random features."
Deflinek wrote:
Yes, the reason is to provide a broad set of rules as a template for you to just cut unwanted instead of creating custom ones.
Each and every rule is accompanied by explanation on the motivation. It is not just a random set of suggestions.
Deflinek wrote:
I'm glad you know what is/isn't more readable FOR ME.
Being readable has little to do with a personal preference. I prefer "begin" and "end." around a procedure, but that does not make it more readable.
Deflinek wrote:
Not a good example here. Single letter variable and two magic numbers :) After two months you will scratch your head equally on both lines :)
A good example; the meaning is not relevant, the time spent on decoding what it says is. It is exact the same information, the only difference is the encoding. One could add a version with hex-values, wich is even more undreadable to most of us since we don't use it that often.
Deflinek wrote:
Again. Those rules are there as a template.
I know it is in the template, I'm asking "why".
Deflinek wrote:
It is better to have a lot of rules that you can customize than have just a few essential ones and write plugins for everything else.
"Here are my rules, if you don't like them, I have others"? Like I said, it is not a random set of suggestions; most of them do make sense.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Deflinek wrote:
Yes, the reason is to provide a broad set of rules as a template for you to just cut unwanted instead of creating custom ones.
Each and every rule is accompanied by explanation on the motivation. It is not just a random set of suggestions.
Deflinek wrote:
I'm glad you know what is/isn't more readable FOR ME.
Being readable has little to do with a personal preference. I prefer "begin" and "end." around a procedure, but that does not make it more readable.
Deflinek wrote:
Not a good example here. Single letter variable and two magic numbers :) After two months you will scratch your head equally on both lines :)
A good example; the meaning is not relevant, the time spent on decoding what it says is. It is exact the same information, the only difference is the encoding. One could add a version with hex-values, wich is even more undreadable to most of us since we don't use it that often.
Deflinek wrote:
Again. Those rules are there as a template.
I know it is in the template, I'm asking "why".
Deflinek wrote:
It is better to have a lot of rules that you can customize than have just a few essential ones and write plugins for everything else.
"Here are my rules, if you don't like them, I have others"? Like I said, it is not a random set of suggestions; most of them do make sense.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
"Here are my rules, if you don't like them, I have others"? Like I said, it is not a random set of suggestions; most of them do make sense.
And this particular one also makes sense for me. Apparently readability is a personal preference, hence this thread.
string.Empty
Is not overly verbose and makes it clear that you intend to assign something an empty string. Not a typo, not a placeholder for future hardcoded key. Just an empty one. This is a prime example of readable code because in the line:
var exclusiveFoobar = string.Empty;
beside of the act of assigning something to the variable you see an intent of assigning the empty string on purpose. It is more readable in the same way as
var verticalAura = turnBackAngle + fancyCouple;
is more readable than
var v = 180 + 69;
-- "My software never has bugs. It just develops random features."
-
Eddy Vluggen wrote:
"Here are my rules, if you don't like them, I have others"? Like I said, it is not a random set of suggestions; most of them do make sense.
And this particular one also makes sense for me. Apparently readability is a personal preference, hence this thread.
string.Empty
Is not overly verbose and makes it clear that you intend to assign something an empty string. Not a typo, not a placeholder for future hardcoded key. Just an empty one. This is a prime example of readable code because in the line:
var exclusiveFoobar = string.Empty;
beside of the act of assigning something to the variable you see an intent of assigning the empty string on purpose. It is more readable in the same way as
var verticalAura = turnBackAngle + fancyCouple;
is more readable than
var v = 180 + 69;
-- "My software never has bugs. It just develops random features."
Deflinek wrote:
Apparently readability is a personal preference
Sorry, but it is not; it is just that, a preference. One that may have many motivations, but not speed of interpretation.
Deflinek wrote:
Is not overly verbose and makes it clear that you intend to assign something an empty string.
It is even against the DRY-principle; it is merely another alias for "".
Deflinek wrote:
It is more readable
No, you are mixing intent with values; without caring about the intent, reading the damn thing, interpreting what it says, takes more time. The more of that clutter in your code, the more time required to comprehend what it does. And still there is no argumentation for the aliassing of an empty string literal.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Well, MSDN[^] says String.Empty is "".
MSDN says:
The value of this field is the zero-length string, "".
So that sounds to me like they are 100% the same (apart from the readability of course ;P )
V.
(MQOTD rules and previous solutions)
While I agree, StyleCop does not. It may be right, it is different to fetch the value of a field than to compare to a literal.
V. wrote:
apart from the readability of course ;-P
Of course, it needs no explanation on the superiour version of encoding information. I can only conclude that the rule is incorrect - I am glad we agreed on the subject :cool:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Cause The C# code includes an empty string, written as “”. Rule Description A violation of this rule occurs when the code contains an empty string. For example: string s = ""; This will cause the compiler to embed an empty string into the compiled code. Rather than including a hard-coded empty string, use the static string.Empty property: string s = string.Empty; How to Fix Violations To fix a violation of this rule, replace the hard-coded empty string with string.Empty.
So..
string s = string.Empty;
..is more readable than..
string s = "";
Since when are two words more "readable" than the two symbols that half the world knows and uses? The word "hard coded" is equally out of place - it feels like it means to warn that the constant "might" change and that it therefore must be wrong to hard-code it. Yes, very likely scenario.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
OK, let's see if this works. Based on a real question from QA. Copy and paste the following code block into Visual Studio:
string s = "";
Console.WriteLine(s.Length);Now explain why the output is
1. :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
OK, let's see if this works. Based on a real question from QA. Copy and paste the following code block into Visual Studio:
string s = "";
Console.WriteLine(s.Length);Now explain why the output is
1. :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
