14

I was reading the MSDN article of the boolean structure, when I saw that a boolean has two fields: TrueString and FalseString. These respectively return "True" and "False".

After some searching, the only example I could find is in this dotnetperls article. The article states:

Programs often need these strings. TrueString and FalseString are a useful pair of readonly members. They represent truth values in string format. They provide indirection and abstraction over directly using string literals.

So appearantly it's useful for some situations. But the same article fails to provide a realistic example (IMHO anyway).

Some further reading also brought this to my attention: TrueString and FalseString are public static readonly fields. And this dornetperls article states:

The language specification recommends using public static readonly fields ... when the field is subject to change in the future.

Now this I can somewhat understand. If the .NET developers ever decide to change "True" and "False" to respectively "OkeyDokey" and "Negatory", it's smart to use TrueString and or FalseString.

But that still leaves me with the question: in what kind of scenario do you want to compare a string with the string literal of a boolean? Because appearantly: "Programs often need" them.

Jordy
  • 1,816
  • 16
  • 29
  • 3
    I can imagine if you're doing your own parsing (and not leveraging `Boolean.Parse` for whatever reason). I would probably argue against that the statement "programs _often_ need" them, but it's plausible that they _could_ be used and it's a pretty low-hanging fruit for the BCL team to include. Presumably the `Boolean.ToString` method also leverages them when outputting so at least in that sense it provides a single/central declaration of what the boolean string representations should be and developers can use it to compare any string outputs from a `bool` rather than hard-coding `"True"`. – Chris Sinclair Jul 03 '13 at 12:07
  • 3
    ...because the .NET environment is designed to support many languages. http://stackoverflow.com/a/491367/284240 – Tim Schmelter Jul 03 '13 at 12:09
  • @TimSchmelter, can you explain why multi-language support is relevant as to why you want to know the string literal of a boolean? EDIT: the question of the link you posted gave me a good example. – Jordy Jul 03 '13 at 12:13

5 Answers5

4

For the same reason that string.Empty exists. Some people prefer a semantically named value in code over a literal one.

In modern .NET (anything after .NET Framework) the following code prints True three times:

Console.WriteLine(ReferenceEquals("True", bool.TrueString));
Console.WriteLine(ReferenceEquals("False", bool.FalseString));
Console.WriteLine(ReferenceEquals("", string.Empty));

This tells us there is zero runtime difference between the literals and the fields. They are exactly the same object at runtime.

Try this for yourself on sharplab.io here.

Others have mentioned using it to compare with when parsing boolean strings, but I would not recommend that. If you want to convert a string to a bool, use bool.TryParse or bool.Parse. Using == does a case-sensitive comparison, which is probably not what you want. Furthermore, the framework's methods are optimised specifically for common cases. You can see these optimisations in the code on GitHub here: https://github.com/dotnet/runtime/blob/f8fa9f6d1554e8db291187dd7b2847162703381e/src/libraries/System.Private.CoreLib/src/System/Boolean.cs#L226

Drew Noakes
  • 300,895
  • 165
  • 679
  • 742
2

If the program stores data in a human readable file or database, it may need to store values as strings. When you read the data back in, if you know the data was written by your application and uses a standard string representation, you can compare x == bool.TrueString faster than you can bool.TryParse(x ...). You could also validate the data by making sure all values x == bool.TrueString || x == bool.FalseString

If the data was typed by humans, or a different system, TryParse is a better option, as it accepts more values as true and differentiates between a definite false and an invalid input. (MSDN Boolean TryParse)

Denise Skidmore
  • 2,286
  • 22
  • 51
0

It can be used as a default value for missing "stringly-typed" configuration parameters. Here's a concrete example I've recently used:

 if (bool.Parse(ConfigurationManager.AppSettings["IsTestMode"] ?? bool.FalseString)) ...

...which is - in my humble opinion - simpler and more readable than

 var isTestModeString = ConfigurationManager.AppSettings["IsTestMode"];
 if (isTestModeString != null && bool.Parse(isTestModeString)) ...

(I deliberately do not use TryParse here, since I do not want to silently ignore invalid values. I want an exception to be thrown, if the configuration value is present and something other than True or False.)

Heinzi
  • 167,459
  • 57
  • 363
  • 519
0

There are many situations where you may need to compare if a string is equal to "True", such as checking an API response. Note: it's more efficient to compare strings but often safer to parse.

The only advantage to using the built-in properties is you won't make typos (assuming you have Intellisense) and you don't have to remember the casing (e.g. "true" instead of "True).

SendETHToThisAddress
  • 2,756
  • 7
  • 29
  • 54
-1

In easy words. Boolean is a Structure. this boolean expose ToString() method which represent a human readable text for the users. So if you write some thing like. 

bool b = false;
b.ToString();

the output will be the "False" insteed of 0. the "False" is readable by human and easyly being captured.

Also some where you may want to parse a text value to a boolean value. so these also can be represented as boolean values. for example. we use 

Boolean.TryParse("false" ,out mybool)

the false value is being set by the Tryparse method as this finds that we can read values from strings tool.

JSJ
  • 5,653
  • 3
  • 25
  • 32