What is the proper way to declare a Microsoft class to use in my code. The quick and dirty way I am doing it here, I know, is not correct

[complete]

What is the proper way to declare a Microsoft class to use in my code. The quick and dirty way I am doing it here, I know, is not correct

> Microsoft SharePoint.Client.List newList = null;

I think it is something like this

> Microsoft.SharePoint.Client.List newList = new Microsoft.SharePoint.Client.List();

Basically, the warning message I am getting makes me uncomfortable:

 

[Skydiver]

It's because you are trying to use "new" C# that has nullable checks with a library that was originally written for "old" C# where all reference types could potentially be null.

So with new C# you would write:

Microsoft.SharePoint.Client.List? newList1 = null;

where as old C# would just let you get away with:

Microsoft.SharePoint.Client.List newList1 = null;

In general, in C# you don't need to pre-assign null to variables like you would in C++. In C#, reference types default to null, and value types default to their "zero" value.

 

[complete]

Thank you for your response !!
I will do that '?' thing you suggested.

Update, the squiggly line under the null reference went away which tells me your suggestion was spot on accurate.

Thanks again !!

 

[cjard]

Seeing the squiggly line go away doesn't necessarily mean it was the right thing to do

Using the question mark is you stating to the compiler "this thing might be null sometimes, let me assign null to it and then check everywhere else that I use it, that it isn't likely to have become null recently"

It is intended to help prevent what is possibly the most common form of crash in code, NullReferenceException

We should typically look for ways to avoid having nulls hanging round in our code , so instead of declaring the var using ? to inform as "might be null sometimes", is there any way you could make sure it isn't?

Give it a value right now

If that's too soon (you don't know all the data you'll need to create it) then create it later when the time is right

If you're declaring outside eg a TRY because you want to set it in the try but use it later, outside the try, then don't give it a value at all, just have:

Thing t;
try{
  t = GetThingThatMightFail();
}catch ...{
 //return or throw here
}
t.DoSomething();  //if you don't return or throw above compiler will complain because c# can reach to here with an unassigned t

Slapping ? on everything just means the compiler will start putting wiggly lines in other lines later on saying "this might be null here" because it can see you've declared it and set it null but it can't see you having set it to something not null before you started using it. This means you need to definitely set it or start filling your code with "if blah equals null then.."

 

[Skydiver]

Great advice for modern programming in C# in general.

Unfortunately the CSOM library was written all the way back in the early 2000's and does not incorporate a lot of the modern object oriented philosophies. Even worse, it was written by people who were developing with the mindset of "C++ is just C with classes" and translated that over into C#. Add on a database transactional model because their background was more grounded in databases rather object orientation where you need to call ExecuteQuery() to actually hydrate objects. As a cherry on top, the hydrated object may not fill all the fields -- you need to ask for those fields! Letting the compiler do null checking is not really helping you much in this case. It'll be like putting on surgical gloves before mud wrestling. Your hands will clean, but you'll still be covered in mud.