|
Yet another example of inaccurate code comments:
The Empty constant holds the empty string value. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So "" != String.Empty ? 
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Nope, it's much better!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wait, what? You know you can't get high on diesel.
Or are we still excited with that extra 40% per gallon by switching fuels?
Sin tack
the any key okay
|
|
|
|
|
Lopatir wrote: You know you can't get high on diesel.
Well, technically.. Continental Diesel
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
What!!! I've been extremely anal about using string.Empty instead of "" and you tell me it's the lesser option.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Run this code
if (ReferenceEquals(string.Empty, ""))
{
Console.WriteLine("\"\" is the same as String.Empty");
}
String.Empty and "" are likely to reference the same memory location so they are effectively the same (There's a name for this combining of string resources but I forget what it is). The problem with using String.Empty as a default value for a function parameter is that it's not a COMPILE time constant. The value stored in String.Empty is a reference to the string "" stored in memory and that reference doesn't get set until the program starts and the string "" gets loaded into memory. Because how can you have a reference to a memory location before the program has started?
So basically this error message is 100% accurate. It wanted a compile time constant but was given a runtime constant and it said "That's not good enough, mate".
|
|
|
|
|
I wasn't too serious
However, I think it would make sense if Microsoft actually allow parameters to have a default value of string.Empty instead of "". It's always been pushed as being a bad practice to have 'magic strings' in code.
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
It's not a constant.
From the CLI source:
public static readonly String Empty = "";
98.4% of statistics are made up on the spot.
|
|
|
|
|
If it is set to readonly so can never change, doesn't that make it constant?
|
|
|
|
|
No. A constant isn't actually a variable, it just looks like one. When you write this
const string x = "Hello";
if (x == "Hello")
{
Console.WriteLine (x);
}
what gets compiled is this;
if ("Hello" == "Hello")
{
Console.WriteLine ("Hello");
}
The compiler does a "find and replace" and in-lines the value of the constant. That is why a constant can't be an object.
const Person p = new Person();
p.Firstname = "John";
Console.WriteLine(p);
|
|
|
|
|
They work very differently and you can nuke a readonly with reflection. (and with unsafe, and in some odd corner cases with structs)
A constant is so constant that even if you have some constant in a DLL and you change it/recompile/replace the DLL, the application that uses the DLL still uses the old value. You also can't even try to change them with reflection, there is nothing there to attempt to write to.
A readonly is not directly writable, in all other ways it's a normal field.
|
|
|
|
|
Maybe we should have a modifier "SetOnceReadMany", to describe something that is not a "constant" in the sense of a literal, but will always return the same value when read. At least in a given run it returns the same value - not necessarily under varying conditions, such as moving your code to another operating system. The value is not modifiable (hence 'constant'), but depends on the OS (or some similar external condition.)
|
|
|
|
|
Does not help.
It still needs to store the string somewhere, even if the string is ""
and once it does that, (1) what's stored at that location can be externally modified after compilation and/or during execution.
Sin tack
the any key okay
|
|
|
|
|
Sure, even if the value is burnt into a ROM, you can unsolder that ROM and put another one in place. So you can set Environment.NewLine to "xyzzy", if that satisfies you one way or the other. But that will neither change the newline convention in Windows, *nix or OSX.
I've seen people, in classic K&R C, set up #define to give FALSE the value 1 and TRUE the value 0. And I've heard of people programming in Forth to set the value of 3 to 17 - in that language, the literal 3 is a symbol that just happens to initially have the value of e.g. the count of x-es in the string "xxx", but it can be redefined som something else. Aa a code obfuscation mechanism, it is of course great.
I think that when you work in a given language, your task should be solved in that language, using the abstractions and concepts in that language. If it says that a value is constant, it IS constant for that problem solution. Just like you can go behind the compiler's back and change a contant value, you can also open an .exe or .dll file before it is run and change a "greater than" conditional jump to a "greater that or equal to" conditional jump. So the loop termination, while appearing to be constant at the source code level, is actually varying depending on which modification are made to the executable code file.
If you start digging a huge hole in the ground underneath your house, your house will fall into it. You asked for it, you got it.
|
|
|
|
|
Bro...
Readonly field / variable is not the same as constant.
I thought it was a very basic knowledge.
It seems that I was wrong.
|
|
|
|
|
Since it's actually a static field then it could be anything.
|
|
|
|
|
You should give your variables meaningful names.
|
|
|
|
|
F-ES Sitecore wrote: You should give your variables meaningful names.
I'm sure it was just an example but how do you know it's not meaningful anyway?
Sin tack
the any key okay
|
|
|
|
|
It was only a joke 
|
|
|
|
|
StyleCop: missing joke icon. 
Sin tack
the any key okay
|
|
|
|
|
Haha, that's a good one.
While we are at it: How about truths, are they jokes?
Like: Constants aint. Variables won't.
(Maybe these are not absolute truths, even though you sometimes get that feeling.)
|
|
|
|
|
Lopatir wrote: missing joke icon
This is a form of natural selection.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Tell him there's no functions in C#.
|
|
|
|
|
I raise you a SQL error..
[Error Message]
TITLE: SQL Server Setup failure.
SQL Server Setup has encountered the following error:
The given key was not present in the dictionary..
For help, click:
BUTTONS:
OK
[/Error Message]
In the end, it was not happy about an IP address in the cluster.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
