default values

[Jon Skeet [C# MVP]]

I guess I wasn't being clear enough, sorry about that.

Thinking about it further, my opinion is that it actually makes sense to
explicitly initialize *all* value type variables, whether local or member
level. I like everything to be explicit, and I think this is more consistent
with the C# philosophy (where casting is also explicit, for example). For
member level, initialization could occur as part of the declaration, or in
the constructor(s).

I think the default null value for reference types makes sense and should be
implicit.

Do you disagree with that?

Yes - if reference type default values are going to be implicit, why
shouldn't value type default values? That particularly applies if
you're arguing for consistency!

If you want everything to be explicit, there's nothing to *stop* you
from assigning to members when you declare them - but I don't see why
it should be enforced. It's not like they have undefined values
otherwise or anything nasty like that.

 

[John Wood]

Yes - if reference type default values are going to be implicit, why

shouldn't value type default values? That particularly applies if
you're arguing for consistency!

Because it's clear that a reference type can have a value of 'unset', which
is null. Value types, however, can never be 'unset', so they must have a
value -- and it's not clear to the person reading the code what that value
might be. Sure you learn these things as you go, and I suppose you can look
up documentation, but I don't recall seeing a list of default values for
valuetypes in the language spec (I may be wrong), and there's the
possibility that other implementations of the CLR may provide different
defaults.

They could at least have provided a warning for it...

 

[Jon Skeet [C# MVP]]

Because it's clear that a reference type can have a value of 'unset', which
is null. Value types, however, can never be 'unset', so they must have a
value -- and it's not clear to the person reading the code what that value
might be.

It's clear to anyone who is familiar with the language, IMO. It's not a
particularly obscure piece of the language - it's well documented, it's
usually covered fairly well in books, etc.

Sure you learn these things as you go, and I suppose you can look
up documentation, but I don't recall seeing a list of default values for
valuetypes in the language spec (I may be wrong)

You are:

http://www.jaggersoft.com/csharp_standard/12.2.htm

and there's the possibility that other implementations of the CLR may
provide different defaults.

No there isn't - the specification for what the default value is is in
the C# language spec. That in turn relies on the CLR spec. Any
conformant CLR will give the same values.

They could at least have provided a warning for it...

I don't see why one is necessary, frankly.

 

[John Wood]

It's clear to anyone who is familiar with the language, IMO. It's not a

particularly obscure piece of the language - it's well documented, it's
usually covered fairly well in books, etc.

I'd be willing to bet that less than half of C# developers can recall the
default value of a datetime type off the top of their head...

If you're so comfortable with default values, then why don't you advocate
automatic default value assignment to local variable declarations?

 

[Jon Skeet [C# MVP]]

I'd be willing to bet that less than half of C# developers can recall the
default value of a datetime type off the top of their head...

Then if they care about the value of the variable before it's first
assigned elsewhere, they should set the value explicitly. There's
nothing stopping you from doing that, is there?

(Care to lay any bets about what proportion of C# programmers know the
default value of an int, btw?)

If you're so comfortable with default values, then why don't you advocate
automatic default value assignment to local variable declarations?

Because there, it's almost always wrong. The compiler *can* make sure
that the initial value is usefully set (in almost every case) so
there's no point in *not* being explicit.

 

[John Wood]

If you're so comfortable with default values, then why don't you
advocate

Because there, it's almost always wrong.

Why so?

The compiler *can* make sure
that the initial value is usefully set (in almost every case)

And so it can at the member level. It just needs to check that an assignment
is made to that variable in either the declaration or the constructor(s).

so there's no point in *not* being explicit.

Consequently there's no point in not being explicit in member variables
either?

 

[Jon Skeet [C# MVP]]

Why so?

Apart from the reasons elsewhere, I feel that member variables are
actually different in nature to local variables. They're less transient
- they represent state, and sometimes state has natural defaults. Local
variables are used during an action, and as such don't "linger" -
somehow that makes a default value less useful for them, although at
the moment I'd be hard pressed to express it better than that.

And so it can at the member level. It just needs to check that an assignment
is made to that variable in either the declaration or the constructor(s).

No, that's not the same thing. For local variables, the compiler can
tell when the variable is first read. For member variables, it can't.
Yes, it could enforce that you had to assign something as you suggested
- but that would mean a lot of assignments which simply aren't
necessary.

Consequently there's no point in not being explicit in member variables
either?

I believe there is - but I can see I'm not going to convince you. I
hope you can at least see that making the rules different for reference
type variables and value type variables would lead to *less*
consistency, not more.

 

[John Wood]

Apart from the reasons elsewhere, I feel that member variables are

actually different in nature to local variables...although at
the moment I'd be hard pressed to express it better than that.

I'll give you a chance to express it better another time... otherwise this
argument will go on forever!

For local variables, the compiler can tell when the variable is first

read. For member variables, it can't.
It sounds like you're suggesting that you may have member variables that are
never read? Otherwise, what difference does it make? As long as it's
assigned a value at declaration or in the constructor, it shouldn't matter
when it's read.

I hope you can at least see that making the rules different for reference
type variables and value type variables would lead to *less*
consistency, not more.

Actually not really! Sorry!
Reference types are, by nature, references to something, in fact I see them
as a container of sorts. I think it's quite natural to assume that by
default this container is empty, what else could it possibly refer to? It's
an obvious default... much like 0 would be for an integer, it's just that
valuetypes get a bit more complicated than integers...

Oh well, perhaps we should just agree to disagree...

 

[Jon Skeet [C# MVP]]

It sounds like you're suggesting that you may have member variables that are
never read? Otherwise, what difference does it make? As long as it's
assigned a value at declaration or in the constructor, it shouldn't matter
when it's read.

No - the difference is that with a member variable which isn't assigned
any value in the constructor or in the declaration, it may or may not
be read before a value is first assigned. For instance:

string name;
public string Name
{
get { return name; }
set { name = value; }
}

Is the Name property going to be set or fetched first? The compiler has
no way of knowing.

Compare this with the local variable case, where the compiler can see
*every* attempt to read or write it.

Actually not really! Sorry!
Reference types are, by nature, references to something, in fact I see them
as a container of sorts. I think it's quite natural to assume that by
default this container is empty, what else could it possibly refer to? It's
an obvious default... much like 0 would be for an integer, it's just that
valuetypes get a bit more complicated than integers...

Oh well, perhaps we should just agree to disagree...

I suspect so.

 

[John Wood]

No - the difference is that with a member variable which isn't assigned

any value in the constructor or in the declaration, it may or may not
be read before a value is first assigned. For instance:

As I said, it shouldn't matter *when* it's read. It can be assumed it'll be
read at some point, otherwise it wouldn't have been declared.

The likelihood is, even the programmer can't be sure what order the code
will run. In fact, this ambiguity provides even more basis for forcing an
explicit assignment during initialization.