Stop reading good practices! This only creates programming addictions and illusion that is learning to program better. Study the fundamentals, understand why things work that way, research and see for yourself or ask experts who can be challenged and evaluated by other people, as you are doing now (in the past was more reliable, today the site evaluates answers with problems as if they were good, so it is also not as reliable).
Did you do the tests? The right way? Are you sure you saw which one is slower? In the right situation? Be very careful with tests that do not have control of the environment. I see a lot of error when the person goes to test and then gives results different from reality. And even if it works, in normal use it may be that the result is different from the actual test and correct, because the code does not run alone. I did the test of Rodolfo’s answer and in my machine, under the conditions of my solution, gave different result, including in different executions the result was not very consistent.
It does not happen, but it could have a compiler that analyzes the whole context (and it is not so difficult in certain cases) and could see that most of it is not necessary and delete everything.
Okay, intuitively I believe I’m right, but only a correct test can guarantee.
The first one does something different from the others, so we’re already comparing oranges with bananas. It checks whether the string is null before checking the content. If the semantics is different already complicates the comparison. Then I have to ask: can you ensure that the string is not null?
I already gave one answer on the subject and this method actually does only two things: it checks if it is null and if its size is 0. So we can already conclude that itself . NET prefers to check the size, and makes sense, because it avoids a comparison with indirect of memory and compares numerically a constant. There we can verify that the IsNullOrWhiteSpace()
is potentially much less performative and wasteful of resources if not what you need, and semantics is different in certain situations.
If you can guarantee it’s not null, then the third option is better. I can state this without testing by the knowledge I have, but it could have some optimization and not be different. Nothing prevents the compiler or Jitter identify what you want and exchange it for a more performatic code. And that can change from version to version, so if you want accurate information, you need to test the version you’re going to use on the platform you’re going to use. Finally, everything can influence.
If you want to ensure the best performance don’t tell us there will be optimization. But rarely is this really necessary.
And of course, I would avoid the latter whenever possible because it tends not to be optimized. I’d rule out the first one if I made sure it’s not null, which I usually guarantee now and more in C# 8.
If anyone finds a reason to use another way, they need to justify.
As a useful note, in C# 8 it is possible to ensure that the string
and other reference types are never null at compile time, so any comparison with null is unnecessary unless the type is declared as null (string?
).
Note
This part no longer makes sense because the question has been edited, but it can be useful for other people.
Finally in that specific case posted on the question I would do so (that’s right, it’s not viewing error):
If I declare a variable of type string
and not putting any value it will be null for sure, you have nothing else to do, nor need to check if it is null, even more if you have something. And of course, examples 2 and 3 will go wrong. So it’s not good practice, it just makes sense to do nothing. I answered considering that the example was a mistake and the intention is in another context.
I would declare string Ret = String.Empty; only
– Amadeu Antunes
Thanks for the remark, I’ll edit the question. I put it that way only to exemplify the existence of that string, but it can generate doubt because, in this case, always give Nullpointer in examples 2 and 3.
– SUR1C4T3