|
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
|
|
|
|
|
Non-printable characters.
Three of them, according to the hex-editor
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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)
|
|
|
|
|
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
|
|
|
|
|
It becomes more readable when you use it as a standard, it isn't just string that supports Empty and your own classes should too (if relevant).
public class Person
{
public int ID { get; set; }
public string Name { get; set; }
public static Person Empty
{
get { return new Person {ID = 0, Name = string.Empty}; }
}
}
class Program
{
static void Main(string[] args)
{
string myString = string.Empty;
Guid myGuid = Guid.Empty;
Person myPerson = Person.Empty;
Console.ReadLine();
}
}
|
|
|
|
|
From my point of view string.Empty conveys the intention that the string is not to be null and have no characters.
Seeing a magic value like "", and let's face it - it IS a magic value albeit a simple one, always makes me question the code: "Is that supposed to be like that, or was there some value forgotten in debugging?"
I have yet to encounter having to use an empty string as a case in a switch, but now that I know I will try to avoid that, or use a const value.
|
|
|
|
|
sibling123 wrote: From my point of view string.Empty conveys the intention that the string is not to be null and have no characters.
So do two quotes.
sibling123 wrote: Seeing a magic value like "",
Two quotes are no magic value, but a global constant expression.
sibling123 wrote: I will try to avoid that, or use a const value.
Duh. SA1122 is simply nonsense.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
