|
I suppose it's a bit like const. You can't just sprinkle a few around the place, you have to go all-in.
Paul Sanders.
If I had more time, I would have written a shorter letter - Blaise Pascal.
Some of my best work is in the undo buffer.
|
|
|
|
|
Yes, I fix them. And I only add ! if I can verify the value can't be null and I am not able to rewrite the code so the compiler sees it as well. It does become a mess if using an old .NET version without the "required" keyword, so I am refusing to use anything old now.
This is not just a response to other languages (though competition of course means you can't just ignore problems), but a response to something that is a fundamental design error in the type system of C# and many other OO languages that copied Tony Hoare's "billion dollar mistake".
|
|
|
|
|
I fix most of them, but I'm not afraid to use ! (even the phrase null!) or Debug.Assert(thing != null, "the thing") or some of the nullability-related attributes. I don't think we should drink too much of the Kool-Aid, I don't aim for perfectly "pure" use of Nullable. Using it doesn't really bother me in code that already makes use of it, there aren't tons of spurious warnings in that case, but converting a medium-size codebase to enable Nullable was a chore (that process did reveal a couple of bugs that were actually bad and had evaded detection up to then).
No doubt the main thing Nullable prevents is trivial mistakes that would be noticed immediately when pressing F5 anyway. (beginners seem to live in total fear and terror of the NullReferenceException, but let's be real, it's usually no big deal) But since converting a codebase to use Nullable revealed a couple of actual bugs too, well those bugs would never have existed if Nullable had been enabled all along, so maybe it's doing something serious too.
It's not effort-free to use, and the payoff is in something not happening, it's impossible to know what didn't happen, so who knows what the cost/benefit ratio is?
|
|
|
|
|
Some people seem to find some computer idioms and technologies difficult to understand.
And then they then attempt to popularize that poor understanding as being a failure in the idiom/technology rather than leaving it where the problem actually belongs.
Myself I like null. Easier than coming up with a long list of magic values that represent the same thing as 'no value'.
|
|
|
|
|
No one is suggesting you should not use null.
The nullable check makes it explicit where you intend to use it - just as it already is for value types.
|
|
|
|
|
lmoelleb wrote: makes it explicit where you intend to use it
Your assumption is that I do not understand what it does. You are incorrect in that assumption.
|
|
|
|
|
Then I misunderstood your post sorry - and I still have no idea what you where trying to say.
|
|
|
|
|
That annoying nonsense started with .NET 6. I'm trying to be a good and obedient Microsoftie, leave Nullable enabled and deal with it in the code like they suggest. So I use truck loads of ! signs when I know good and well that it will not be null whether or not VS can see that I am checking for null values before referring to the object.
The most annoying place it warns me of possible nulls is for string properties in a POCO. Seriously, MS, most of the time it doesn't make any difference whether or not those strings are null or not and warning me that they may be is useless and generates a false warning.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
We do, and at first I hated it, but now I've embraced it. We find it cuts down on lots of null-ref opportunities.
Sure, it can be annoying sometimes, but the occasional "!" on the end of a var, combined with the much nicer "if x is not null" makes the code very clear. Assuming you know what a trailing ! is...
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Assuming you know what a trailing ! is
You nailed it on its ! head. Time to google. Technology keeps leaping forward and I am stumbling around trying to keep up while at the same time wondering why I'm trying to keep up. 
|
|
|
|
|
I hear ya.
Reminds me of the 2 day long conversation Matthew and I had about the extra negation inif not "!arg_name:enableGPU=!" == "!arg_name!". I didn't see the double negation. He's pointing at his screen (over FaceTime) saying "there!". The issue was the "!" meant delayed expansion of a variable substitution in the Batch file, but to any reasonable developer it's "not arg_name".
We imbue symbols with way too much meaning.
cheers
Chris Maunder
|
|
|
|
|
All the time, and I fix the warnings if they come up. It’s greatly reduced the number of null exceptions that get thrown. I’d prefer it though if they were reported as build failures by default.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|
|
I have been using it on all of my work and hobby projects since it was introduced to .NET.
#nullable #enable 🤣.
|
|
|
|
|
Agree these warnings are pretty annoying in a project that didn't start out using nullable ref types correctly from the start. I have a large project in this situation, and fixing all these warnings is pretty daunting, requiring significant rework and refactoring. But I've come to see the value of using nullable ref types, so I've adopted it in smaller projects, and have been using it going forward. It's just not feasible to retrofit in all cases.
|
|
|
|
|
Yes, I use it, and I like it very much. Removed all possible NRE, and it's perfect to make sure juniors do not introduce tons of bugs. Sometimes a IF xx != null is enough, some other times we need "!", I hope the compiler could become smarter like Typescript is.
|
|
|
|
|
rallets wrote: and it's perfect to make sure juniors do not introduce tons of bugs
Null pointers are not significant, to me, in production.
Logic errors however are.
And the only way to prevent that for juniors and seniors is meaningful code reviews.
|
|
|
|
|
This entire push to eliminate Null is misguided. The reason is that in the real world sometimes you really have no information, which is what Null represents. Look at numeric data types, zero is not the same as NULL. Zero is a value but NULL represents no value. This is a fundamental semantic difference.
|
|
|
|
|
Generally the idea is thus...
Someone misused it - thus it must be a problem.
Then they come up with an idiom that could fix it, that single problem, while introducing other potential problems (like using magic values for no value) and then proclaim that the world is a wonderful place.
Thus hoping that a technology fix can absolve them of relying on process (non-technology) solutions which have been proven (studies) to reduce problems.
|
|
|
|
|
I fully agree with everything you wrote, however, nullable checking is not necessarily about eliminating the use of null per se. It's about telling things that can legitimately be null (then it reminds you to check) apart from things which should never be null (then it reminds you to not put a null in there).
|
|
|
|
|
Not using .Net 7 yet, but using this in .Net 4.8, .Net Core 31, 5, and 6.
Yeah, the warnings can be annoying, but the benefit can be significant too. Especially with junior devs who aren't used to null checking everywhere/don't have the experience to spot all the potential problems... but it's good for us oldies too, everybody misses stuff sometimes.
The first warning in that list is the one that annoys me most. There are several potential work arounds depending on the specifics, but I often feel none are good 
|
|
|
|
|
It only makes sense for ASP.NET services or maybe new code bases that its critical you don't have null.
.NETFW, Unity3D or other C# projects that heavily use older .NET frameworks its a nightmare.
Only new code that uses new APIs does it work well.
|
|
|
|
|
Rear meat game (10)
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Too easy! Better double!
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
They're always easy if you know the answer Peter  and I think you meant bet double
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
One of those ones that leap out of the screen. Better bet double, maybe. 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
