0

I am working on a project where a lot of the data classes look like this:

[DataMember]
public List<SpecialOpeningHours> SpecialOpeningHours { get; set; } = new List<SpecialOpeningHours>();

I've never seen this before and would normally just do this:

[DataMember]
public List<SpecialOpeningHours> SpecialOpeningHours { get; set; }

Can anyone explain why the list in instantiated in this way and whether or not there is some advantage? It doesn't seem to make any difference in use. I am using Dapper and get the same result populating the list either way.

Norbert Norbertson
  • 2,102
  • 1
  • 16
  • 28
  • 2
    The difference is that `SpecialOpeningHours` is `null` in the second version. – René Vogt Nov 22 '17 at 10:12
  • 1
    "It doesn't seem to make any difference in use." Well it does, in that in the latter case you start off with a non-null value, whereas in the second case you start off with a null value. How is that not different? – Jon Skeet Nov 22 '17 at 10:12
  • Have a look at https://msdn.microsoft.com/magazine/dn802602.aspx – MakePeaceGreatAgain Nov 22 '17 at 10:13
  • Well it doesn't make any difference in populating the list. There's no value to me in having an empty list versus a null. But thanks for point it out. You should have answered. – Norbert Norbertson Nov 22 '17 at 11:42
  • From [Microsof guidilines for collections](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/guidelines-for-collections) "DO NOT return null values from collection properties or from methods returning collections. Return an empty collection or an empty array instead." Is there a "logical" difference for your software in having a null vs an empty collection? if not, an empty collection will save you from nullpointerException if the caller does not check for null – Gian Paolo Nov 22 '17 at 12:15

1 Answers1

1

Your first example is just a shortcut introduced on C#6 for this:

public MyClass()
{
    this.SpecialOpeningHours = new List<SpecialOpeningHours>();
}

Now compare this with:

public MyClass()
{
    this.SpecialOpeningHours = null;
}

The former is what your first option is translated into when compiling, the second one is what you get when you don´t add any initial value. In particular your second example will cause a NullReferenceException as soon as you call any of its members, whereby the first one will run fine.

MakePeaceGreatAgain
  • 35,491
  • 6
  • 60
  • 111
  • thanks, makes sense now. It might be useful to have an empty list by default but that would imply that the data base returned no data. I think I prefer having it null until is has been populated. – Norbert Norbertson Nov 22 '17 at 11:45
  • Defaulting to an empty list would only apply for lists, what if you´d have an `IEnuemrable` instead, or even any other interface? How should compiler know to what the property should default? Of course you have to set this value in any way. Moreover an empty list might indicate few different things: for you it´s a no-data from DB, but it doesn´t *have* to. It might also mean that the list hasn´t yet been filled, where values will come soon. – MakePeaceGreatAgain Nov 22 '17 at 11:52
  • Just looked over an old Entity Framework project. It's interesting to note that where the models are generated by EF the members are not instantiated as new empty lists either. I can see the advantages of instantiating them though and will consider using it. – Norbert Norbertson Nov 22 '17 at 12:11