If you want your property to have a default value, give it an actual default value, not the explicit absence of one (kind of defeats the point to set a default value of null).

It doesn't defeat the purpose of a default/initial value because it shows that it should be filled.

When I'm using hooks in React this is very common.

You must give an initial value, and at some point in the future you will update it.

By setting the value as null initially I can easily check whether the variable has been filled or not. This is most important for initially rendering the UI.

I think the parent comment was saying that you could always make that explicit.

> By setting the value as null initially I can easily check whether the variable has been filled or not

I don't think there's anything wrong with this but it does mean your variable can be in two states~, one where "it shows it should be filled" and one where the value is present and can be used.

You can use null for this if you want and most programmers will understand these states. You can also choose to make this even more explicit by creating a type that expresses this.

example in Kotlin but you get the idea (applies to any variable in any language)

    sealed class ThatVariableYouCareAbout {
     object ShouldBeFilled: ThatVariableYouCareAbout()
     data class HasBeenFilled(val x: String): ThatVariableYouCareAbout()
    }

    // usage
    fun test(thatVar: ThatVariableYouCareAbout) {
      if(thatVar is ShouldBeFilled) {
         //
      } else if(thatVar is HasBeenFilled) {

      }
    }

Seems overly verbose but that's the reality of the variable you're talking about. This represents those states you described. `null` is a crutch in most languages for representing this state and the cause of a lot of subtle bugs (people use it to reset/clear out values too which in reality could represent a different state depending on what you _really_ want the variable to represent).

All that being said, null is generally understood to have this meaning~ and I have/do use it but with an understanding that it's of lazyness/not wanting to be overly verbose (language consideration).

The case you are describing is very familiar to me (rendering UI with initial states through a framework like react) and having an explicit type for the initial state is the ideal, or at least the most explicit, solution.

Option works for 2-state variables like this

null is not a very good default value in most cases though, since the operations you do with values of "real" types will not work on null. Therefore actually using your "default" value is pretty much guaranteed to be a bug, identical to using an uninitialized variable.

It would be better to just error out and not allow the uninitialized usage at all, but unfortunately that's not possible in Javascript.

That's the point though. I can easily do a null check to handle whether or not to process/use the value.

For instance, if I'm fetching some data I usually want to initialize the data variable as null for a couple of reasons.

1) null is not truthy, empty arrays and objects are

2) It shows that the variable is supposed to be filled, unlike undefined