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)
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
-
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)
I always go with "" now. There are some situations where string.Empty is disallowed, because it is not a compile-time constant (which itself is a major weakness of C# in my eyes - the lack of const-correctness and compile-time constructs). So, as I sometimes have to use "" anyway, I eventually just gave up on string.Empty, so at least my usage pattern is consistent.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
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 are contexts in which "" is the only acceptable form, as C# has no compile-time constants so string.Empty is invalid in some contexts. I can never remember exactly when it is invalid, so eventually gave up and started using "" everywhere. (Side rant - one of C#'s major failings in my opinion is the inability to express const-correctness, immutability, and compile-time constants - it leaves potential to have incorrect implementations of interface functions etc.)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
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
why not use: var s = string.empty?
-
why not use: var s = string.empty?
First, there is no need for "var"; it is preferred to use the string-datatype. Second it would also be preferred to use a literal (or a constant pointing to the literal), not a class-member - that's what this entire thread was about. "var" would be useful if it was a linq-query, but it is not meant as a replacement for those cases where you know what type to expect.
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)
A bit late, but: Don't use function names with "empty"[^] ;) If you don't feel like checking out the article, the gist of this item is that the word, "empty" is ambiguous: it can refer to either an action on, or the state of an object. While in your particular example the use of "Empty" seems clear enough, it's inherent ambiguity still makes you hesitate for a moment, whereas the meaning of "" is instantly clear.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
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)
Eddy Vluggen wrote:
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.
In the beginning, I used string.Empty, until I tried to use one in a switch block, and the compiler balked, because it is not seen as a true constant. Hence, I created a true constant,
EMPTY_STRING, and made sure that it is in my root namespace, which I import into virtually every project more complicated than Hello, World. There are many more such goodies where that one lives, in my my DLLServices2 Class Library on GitHub.David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
