Resolved Why booleans start false instead of true ?

Hi,
for some reason, my booleans (if not set) start at the state "false".

I don't understand because I already used Unity in the pass and the default state was "true".

Is it possible that I checked an option somewhere by mistake?

Thanks!

 

The default state for bools has always been false.

This is not a Unity thing, it's a C#/.net/mono thing.

Really programming in general defaults booleans to false. Because booleans generally are associated as a binary bit value of 0 or 1, where 0 is false, and 1 is true. And 0 is also the default value.

For example see something like bitarray which is a compact way of storing lots of boolean values:
https://learn.microsoft.com/en-us/dotnet/api/system.collections.bitarray?view=net-7.0

...

Why?

Tradition.

False = Off = Zero

I don't recall this ever being true (unless it was in say unityscript or boo, which I didn't use... but I doubt it was). I think you may just be misremembering and actually equating them true in your code as default.

And I've been using Unity for going on 12 years now.

 

C# bools are false by default, as Lord points out above.

BUT... there's a lot of different ways those fields get set in a Unity context.

Serialized properties in Unity are initialized as a cascade of possible values, each subsequent value (if present) overwriting the previous value:

- what the class constructor makes (either default(T) (false) or else field initializers)

- what is saved with the prefab

- what is saved with the prefab override(s)/variant(s)

- what is saved in the scene and not applied to the prefab

- what is changed in Awake(), Start(), or even later etc.

Make sure you only initialize things at ONE of the above levels, or if necessary, at levels that you specifically understand in your use case. Otherwise errors will seem very mysterious.

Field initializers versus using Reset() function and Unity serialization:

https://forum.unity.com/threads/sensitivity-in-my-mouselook-script.1061612/#post-6858908

https://forum.unity.com/threads/crouch-speed-is-faster-than-movement-speed.1132054/#post-7274596

 

Thanks to @lordofduct and @Kurt-Dekker, that helped my understanding a lot.
Resolved.
Thanks again.
B

 

A popular programing style is not to rely on default values. That's not to do with you "does bool default to true?" problem -- almost all languages use the same defaults and they're obvious once you know them. It's two other issues:

Number one, it's tough to know when defaults are set -- C# sets defaults sometimes, and makes you do it other times. Sure, you can remember when, but it gets worse. People, even game programmers, ouse different languages and they say you do or don't get defaults using different rules. In fact, I recall one time people were writing C++ in visual studio, it ran fine there, but the real target was Linux and it was crashing. The problem was that official C++ didn't set defaults ever, but Visual Studio C++ set them just to be helpful and people were using that in VS without realizing it wasn't a real rule.

Number two, typing them out can make code easier to read.

bool cows;

looks like you haven't decided what it should be yet. Maybe you're going to compute it in Start().

bool cows=false;

says you thought about it and want it to start at false.

For more, google things like "coding relay on default values".

 

Note to OP: Specification of default values in C#

That's not really a style, it's mandatory. Even in softer languages like ActionScript vars would be assigned a special value of "undefined". Contrary to what this means, they're strictly defined, which allows testing for argument omission, for example (by doing

arg === undefined

). In all strongly typed languages, like C#, declaration and definition are explicitly differentiated. Declared variables are strictly undefined (until a value is assigned to them) and any attempt to consume their state would throw an exception; this is a compile-time check, so there are never run-time 'undefined' states.

This is pure declaration

Code (csharp):

1. int someVar;

Then you're supposed to assign a value

Code (csharp):

1. someVar = 5;

This is known as a compound initialization, and it's a syntactic feature to improve readability and spare a line

Code (csharp):

1. int someVar = 5;

There is however, something called "unspecified" (sometimes also called "undefined" in docs, whereas they call the other thing "uninitialized") which is when a certain implementation detail would produce a value that must be treated as platform-dependent or otherwise unreliable — typically methods with

out

arguments do this, even though assignment of such arguments inside the method is mandatory by design. See for example

TryParse

for types such as

DateTime

or

float

.

In other cases, implementation spec will state a specific value, for example Dictionary's

TryGetValue

explicitly returns a default value if a key was not found. Default in C# is very exact and is strictly specified here. OP can see that the default value of

bool

is

false

. Although I'm sure all languages do this to align with common sense, this is just a matter of convention.

Not really true, the only assignment C# does automatically is array auto-filling, for safety reasons. And even then, this only happens when you define an array (via

new

allocation), not when you declare it.

Edit:
Forgot to say that all class members (fields and auto-properties) are auto-assigned a default value (unless overriden). This is probably what you're meant, but let's clarify your "sometimes".

 

It's tough but really helpful to read the Q. It's obviously a question about class members (variables in a script outside of any function). The OP has booleans which were "not set" and was surprised by the default values assigned to them.

Now that everyone is on the same page, do you think it's better to write

bool cows=false;

for script globals, even though

bool cows;

does the same thing? Maybe put that at the top to help the OP, then the part about how wrong I am about some other stuff could be down below.

 

@Owen-Reynolds All of it was meant to be read by OP, it wasn't intended as a private criticism of your post. Maybe quotation gave a wrong impression. It's just a clarification, to fix your wording and explain a couple of details, not that you were completely wrong.

Anyway, I only half-agree with

bool cows=false;

but that's my personal opinion as I never do that, though there are exceptions and when I do it, it's never by accident and I probably want to say something. In any case, I usually completely document all my fields unless the whole class is self-explanatory. Now, that would count as a programming style.

In general, it's always better to be as explicit as possible. However, this may also clutter the code, and make it less readable. This is why I would never claim any extreme to be better.