|
Kornfeld Eliyahu Peter wrote: I wonder who will pay the bill at the end
Oh, that will be us poor customers.
|
|
|
|
|
Well, I saw such type of code also at the then biggest vendor of hospital information systems...
But they were one step better than your example: they stored the return value of the call to third party in a variable, which they never checked. That's an enormous step forward already, isn't it?
|
|
|
|
|
Reading this thread reminds me of a short story that I read long ago. I can no longer remember whether I was in high school or college; the only reason that has any relevance is that I have forgotten the story, but not its title, "Insert Flap A and Throw It Away."
I have learned, and am periodically reminded of its importance, that if a function returns a value, even if it is poop, you would do well to check it. After all, if the author thought it was important enough to return, who am I to brush him off by ignoring it?
Plenty of authors have written plenty of functions that return void. In all versions of BASIC, these are called Subs, short for Subroutines. Their author is effectively saying, "I have nothing to report; just trust me."
A couple of weeks ago, I ran across a method that returns void that I wish didn't. The method in question, Console.WriteLine() would be much more useful if it returned a character count, along the lines of what you can get from printf(), but probably aren't. Almost every example I see that uses printf() doesn't bother with the return code. This is so prevalent that I hadn't given the matter any consideration until I started working with its buffered cousin, sprintf(). Along the way, I discovered that both have a return value of type int, which returns the number of characters written. While the newer "secure" print functions in the latest Visual C runtime library return minus one to indicate failure, even the old ones can be persuaded to print nothing and return zero.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
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 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
Making SA1122 nonsense 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
Isn't that obvious?! Using String.Empty will remove that idiotic SA1122! 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
No, string.Empty is rubbish; you need System.String.Empty .
As to the issue with ""; how does the (uninformed) reader know there aren't any non-printing characters in there? 
|
|
|
|
|
PIEBALDconsult wrote: No, string.Empty is rubbish; you need System.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?
The 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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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  )
|
|
|
|
|
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
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 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
