The usual convention is to have extension methods behave like regular methods, I.E. don’t allow them to accept nulls. When looking at foo.Bar(); it’s better if I can just intuit that foo can’t be null because you’re not supposed to be able to invoke the . operator on null.
Of course, I’m entirely guilty of breaking this rule myself. cough Shoudly cough FluentAssertions cough
I’ve always used the Nullable context so typically I’m just using string.IsNullOrEmpty to determine empty strings, I’m already confident null isn’t leaking. But your explanation does make sense.
I’m now wondering why I’ve never just used myStr != ""
The usual convention is to have extension methods behave like regular methods, I.E. don’t allow them to accept nulls. When looking at
foo.Bar();it’s better if I can just intuit thatfoocan’t benullbecause you’re not supposed to be able to invoke the.operator onnull.Of course, I’m entirely guilty of breaking this rule myself. cough Shoudly cough FluentAssertions cough
I’ve always used the Nullable context so typically I’m just using string.IsNullOrEmpty to determine empty strings, I’m already confident null isn’t leaking. But your explanation does make sense.
I’m now wondering why I’ve never just used
myStr != ""