With C# 8 the feature (non) nullable reference types was introduced.
We want to use it for development of our libraries.
We found that this feature seems to work only “internally”. Constructors, methods and properties exposed as public API need to check for null values because the user of the library may not enable the Nullable checks.
So, I’m searching for help in the sonar analyzer to identify possible issues.
So far I found S3900 “Arguments of public methods should be validated against null”.
But this checks only a subset, even the rule name suggests null check at all.
I think, with Nullable enabled all public/protected contructors, methods and properties should check all its parameters to be null or throw ArgumentNullException.
Is there additional rule(s) existing or planned?
From what I understand, your suggestion is that RSPEC-3900 (or a different, C# 8 specific new rule, which would be enabled when non-nullability reference types are enforced) should always check for null, and not only when the argument is dereferenced inside the method? (to be sure that null will not be propagated inside the non-public parts of the code)?
Yes, @Andrei_Epure.
When using non-nullability feature I want to ensure not getting null values from outside library.
Without non-nullability feature RSPEC-3900 seems to be sufficient.
With non-nullability activated ALL parameters must be NOT NULL, except explicitly specified nullable.
What means “next rule specification sprint”? When this topic can be discussed in detail?
Do you think, there will be a chance to specify and release such rule in the next few months?
If the rule is approved I would be happy to contribute the implementation.
For my team I need to know quite soon whether we can trust in SQ in future or we have to build our own solution (e.g. private analyzer).
We do sprints just to specify new rules. I don’t have a specific date - but feel free to start a conversation via private messages if you want. I’ve send you a PM and we can continue there.
One of this year’s top priority is adding support for C#8 in the analyzer. So by the end of this year, we’ll do a release supporting C# 8 features in our existing rules.
You can trust us to add support for C# 8 and continue adding high-quality rules for our C# analyzer.
What those rules will be depends - if you need rules very specific to your domain, it’s best to write your own analyzer to complement our own. The question is quite vague.
For me it sounds like we will get a new rule, right?
The only other option I can see is that the compiler will validate non-nullable API based on relevant metadata, like NullableAttribute or NullableContextAttribute even the referencing code does not enable non-nullable feature.
But, this would at least require using c#8 (or above) which we - maybe - cannot ensure.
I appreciate this rule has been a long time coming. Our work on new rules has mainly been in the security space over the last year or so. We are currently ensuring that all C# 8/9 features are supported by the existing rules and then we will turn our attention to adding some new rules to cover the newer language features. I have created an issue for this rule so that we can prioritise. I’m afraid I can’t give you a timeline yet.