Yes, whenever the null is not part of your domain, which is rare to occur.
So bad that in C# 8 the reference types that were null by default cease to exist (If you turn this on, it can’t be mandatory because it would break a lot of code, but I recommend calling whenever possible, even if it takes some work updating code). So if you turn it on, you can only use a null explicitly, for example string?
.
If they are finding a way to minimize their use, why would you encourage use where it is already optional? Yes, you have cases to use, which is why there’s the possibility of declaring a guy as int?
, for example.
In general even in databases should not use null, but there are cases to use. In ORM times you should use even less (although this may make modeling difficult). Good modeling greatly reduces the use of nulls (using null is usually the easy... and wrong way). When you have a null is a warning sign to see if you’re not doing something wrong. But if in the database you are accepting null then it is not option you declare as not null in C#, there has to be a symmetry (if you are doing it in the hand you have some way to minimize it, but I do not know if it compensates the work and if you do it right can be problematic).
There is nothing subjective in this, it is objective that should avoid the null to the maximum, what is subjective is where to do, the judgment will depend on the context, the key that I live hitting, and this is the difference of following good practices. If you look here I have answered about it a few times and I have lectures on the subject.
In the case of types by value has some other disadvantages. One of them is that it takes more space to have control of null. In a double
that occupies 8 bytes will pass occupy 16 bytes (in some cases may be only 9 bytes), even needing only 1 bit to control the null. It is slower, non-atomic and has a number of constructions that does not deal well with null types (works, but happens weird things or has to do some artifice to work, in some cases have to access the property Value
to take the value), and when something expects a int
and will a int?
can give unexpected results in some cases. More reasons to avoid this kind of thing.
C# is strongly typed, to some extent, not 100% and rare are very boring languages :). What the answer here means is that it is statically typed and, contrary to what the answer says, the cancellable types facilitate the code breaking at runtime and that alone is already quite harmful. And the comparison with C++ is completely wrong because integers in C++ cannot be null. And if you’re talking about a type that can be null in C#, before C#8 or after if you don’t turn on the new Feature, can in the same way as C++. And if an annulable integer variable is used in a sum you can guarantee the result by making a conditional before. In some cases you can use an operator such as null Propagation, if you want a null to generate another null as a result.
Completion
Accepting nulls makes the code less robust, less performatic because to give the robustness you have to check that the object is not null before using and because it takes up more space (if the type is not by reference). Forgetting to do this runs the risk of breaking. So avoid its use, some languages even allow the use of null.
Maniero, ask but in cases like this: https://stackoverflow.com/a/9239486/7981707 that the person needs to render nullable?
– Leonardo Bonetti
What have you got? I don’t know if I understand. It’s something that’s not in the answer?
– Maniero
I reread several times and found the answer to my commented question ;)
– Leonardo Bonetti