Hello.
In this lecture, we're going to talk about Question 50, what are Nullarbor reference types when hearing
this question?
You can think it is silly.
After all, all reference types are another in Europe, right?
Well, yes, this is true.
And it didn't turn out with introducing the feature called Nullarbor Reference Stokes.
We've seen our boat before we explain exactly what this feature is about.
Let me show you some code.
Let's say we work on an application that manages houses data.
We use those two types house and address all around it.
Let's see a tiny fragment of this application.
But keep in mind that the entire code base can be huge.
As you can see, this method simply formats a collection of houses as a single string.
All right.
We submit this code for code review and wait for the feedback.
Soon after, we see a new comment looking good.
But if the address of the house is no new reference, exception will be thrown.
You can see Visual Studio warning about that with the green underline, it is true.
After a short discussion with the reviewer will make a decision.
The owner of the house should never be unauthorized.
Also, the address can't be no.
And the Wall Street and no can to be either.
See what happened here.
We made a decision that in this particular case, the Nullarbor type that is screened and address should
actually not be available.
All right.
We have work to do if those properties should not be Nabu.
We must add some logic to the constructors.
Right now, it will be simply impossible to create a house in which the owner's name is nor not an address.
We have no street or no.
We made them practically not knowable, even if as reference types, technically they are Nullarbor.
The problem is.
Visual Studio, before it was updated to support Prop eight, was not smart enough to know that we actually
ensure that the address is not normal, and it would keep giving us the warning about possible no reference
exception.
We could ignore those warnings, but it's not really a solution.
Other developers who are not aware that the constructor is enforcing values not to be known may still
be suspicious and will feel more comfortable with feeling their code was addressed.
Checks for formal values and those checks can be really annoying.
I guess you probably have seen similar cold before such gold sometimes takes a significant part of the
entire cold base, making it bulky, hard to read and unmentionable.
Wouldn't it just be simpler if we could agree the address and its components can be normal and that
we promised to enforce it at the constructeur level?
Well, the need for such agreement was exactly the reason for introducing Nullarbor reference types.
This feature gives us the ability to declare a reference type as knowable or not knowable if a date
is declared as not Malabu.
The compiler will give us warnings in any context in which there is a risk that the value may actually
be known.
If the type is Malabu, the compiler would warn us where another reference exception could happen.
We see sharp, old and new are the old way of declaring reference types.
We make them, not Malabu.
As you can see, the compiler gives us a warning.
We declared the variable as non-Arabic string, but we assigned to it.
This doesn't make much sense, hence the compiler warning we can fix it by declaring the variable as
Abu the same way as we would declare Nullarbor value types by adding a question mark to the type name.
Now the warning is gone.
This variable is another string, so assigning new to it is fine.
A very important note no reference types feature does not change anything in how the program is executed.
Even none of the above values were still strong.
No reference exceptions when all this feature only changes how compiler warnings are issued.
All right, now that we know the essence of Nullarbor reference types, let's take another look at the
address type.
There are no compiler warnings here because the constructor parameters are non-Arab strings.
But let me turn something.
I made the St Parameter Nabu, and now we see a warning.
It is here because we assign another parameter to a long Nullarbor property.
It obviously doesn't make much sense, and it may make this seemingly non-negotiable property.
No, let me show you one more case.
Now, I removed the assignment to the street property completely.
And here is the wording.
Again, it makes sense.
The street property is declared as Nonhlanhla String, but it will be null because it is not assigned
anything.
This actually answers quite a tricky question What is the default value for non Nullarbor reference
types?
Well, ironically, it is more because what else could it be?
The great thing about the Nullarbor Reference Tabs feature is that it has good support from Visual Studio
and other modern ideas.
Let's take a look at the discord here.
The warning is expected because the Nullarbor text may be null, but let me add another track.
The warning is gone because Visual Studio knows that in this line, this parameter is not, nor as it
has already been checked.
Please notice that this support is not infallible and sometimes it can be tricked.
As you can see here, I do something silly.
I declared an array of non-Arab Australians.
Yet by default, it is filled with knows.
No compiler warning appears, though, even if this will troll.
No reference exception because the first element of this error is small, but it doesn't mean this feature
is useless.
Let me quote John Skeet on that.
Being able to know when things might or might not be normal, even when it's only two 90 percent confidence
is a lot better than zero percent confidence.
If you are curious what else Jon Stewart has to say about knowable reference types, check out the recording
of his lecture I linked in the resources attached to this video.
All right.
There are use cases when we actually know better than the compiler, if something is or is not now one
of the outstanding examples is when some field is set with the set up method in unit tests.
If you don't know and you need, let me give you a very quick introduction.
The method with the setup attribute will be executed before each test, so it gives us the same guarantee
as the constructor that this class under test object will not be normal.
Yet the compiler wants us that this field may be normal before exiting.
The constructor C-sharp compiler doesn't know how the unit works, so it's not aware of this field will
never be, nor when the test is executed.
To get rid of the compiler warning, let's declare this field as Malabu.
One warning disappeared, but another showed up.
Now the compiler warns us that the CO2 you might be no one going to the automated on it.
Making the code compliant with the comparison requirements about the Nullarbor reference types is a
bit like playing Whac-A-Mole.
One morning appears, but another pops out.
But in this case, I know better.
I know the setup method will be executed first.
I want to say quite compiler.
I know it's not Noel and exactly for this situation.
The No Forgiving for Giving operator was introduced.
As you can see, I simply put the exclamation mark after another reference type object, which I know
is not now to suppress the warning.
I can actually use this operator even if I know something is small, which is sometimes needed in unit
tests.
Let me show you an example.
First, let's take another look at the House glass.
Even if the address parameters are known, Malabu, I want to perform a nortec here.
This is a good practice.
After all, while still campanas there, because as we said, this feature doesn't change how the code
works, it only issues new warnings.
Of course, the person that caused this constructor will see a warning when passing now as a parameter.
But what if he or she will ignore it after the house object is created?
We want to be sure that we can really trust what was declared that the owner name and the address properties
are not new.
That's why it's best to enforce it once and for all in the constructor.
This looks good after this validation, we can be sure that the owner name and the address will not
be nor unaware in our code, we can forget about the never ending no tax.
The only thing left to do is to add unique test for this constructor.
These tests, drugs, if an argument, no exception will be thrown if the owner name is no.
But even in this test scenario, the computer gives me a warning, but I know what I'm doing.
I want this more here, so I kindly ask the compiler to give me a break.
Again, the new forgiving operator proved to be useful.
Now we understand how noble reference types work.
The question that remains is when should we use them?
Well, my advice is this.
Think about the types in your cold, their fields and properties, as well as local variables and parameters.
Can they ever be more or do you always ensure that they are not?
If they can be, no.
Make them knowable explicitly.
This will clearly show what your intention was, and anyone working with your code will know that this
thing may be new and needs to be checked for it.
Also, a word of caution about migration since the old type declarations are made, not Nullarbor.
Starting with C-sharp eight, it might mean that after updating your dotNet and C-sharp aversion, you
will suddenly get an overwhelming number of warnings.
Don't worry, they are a good thing and will help you migrate to this new future.
But if you really don't want to see them, you can disable this feature in product properties.
The migration process itself can be a bit tiring.
Remember the whack a mole metaphor, but having no reference types can really save you out of pain arrows
and no tax, making the code cleaner, more expressive and easier to maintain.
Even if you don't decide to introduce this feature in an existing product due to complex migration,
I highly recommend using it in a new code.
You can disable or enable this feature per file or even a code fragment.
This way, you can improve your code step by step and not drown in an ocean of warnings.
To disable or enable this feature, we can use the Nullarbor Preprocessor Directive.
As you can see now, the warning is not here, even if we are saying no to another string.
Let's summarize Nullarbor Reference Types is a feature introduced weekly shop eight that enables explicit
declaration of a reference type a snub or not.
The companion will issue a warning when it recognizes the code in which are non-Arab.
Object has a chance of being more or when we use Nabu reference types, we felt Nortec risking the no
reference exception.
This feature doesn't stand up to our way of executing C-sharp code.
It only changes the generated wordings.
This topic is recently quite popular during the interviews, as the future employer wants to check if
you are up to date with modern C-sharp features.
For example, you can hear the question What is the default value of non Nullarbor reference types?
It doesn't seem obvious, but it is no.
What is the purpose of the No.
Forgiving operator?
It allows us to suppress a comparable work related to not ability.
Is it possible to enable or disable compiler warnings related to Norbu reference types on the file level?
If so, how to do it.
It is possible we can do it by using Norbu Enable and Nullarbor Disable Preprocessor directives.
All right, thank you for your attention and enjoy using this feature.