Open rrousselGit opened 2 years ago
Such a feature probably would need an annotation for explicitly marking parameters as optional. Kind of like the @optionalTypeArg
In particular, I'm thinking about copyWith
methods.
It seems to me that there are at least two valid reasons to make a parameter optional:
null
is a valid value for the argument and the author doesn't want to force users of the API to explicitly specify null
, andnull
is not a valid value but is instead being used as a sentinel value (like copyWith
).While I see why this lint would be reasonable where the API falls into the first category, it seems like the lint would be nothing but false positives for the second category. I don't know how often the second pattern is used, but it isn't non-zero.
Within the package under development a user could mark truly optional parameters as such (using the suggested annotation). But the user of this lint will have no such recourse when using an API from a different package. I am, therefore, somewhat concerned about the potential number of false positives.
The same logic could be applied to always_specify_types and its @optionalTypeArg
I think.
It it comes down to that, making a PR should be simple.
And I think it would be legitimate to exclude copyWith
by default. Besides copyWith
, sentinel values are fairly rare
Describe the rule you'd like to see implemented
The idea of this rule is to basically act as if every single parameter has the
required
keyword. The idea is that as opposed to therequired
keyword, this lint would be an opinionated decision from the team maintaining using this lint. In a way, this is very similar to that ofalways_specify_types
. Teams enabling this voluntarily accept more verbose code for safer code.Always passing all parameters of functions can help maintain code by making it explicit that a value isn't specified. For example:
vs:
With the former, you know for sure that this usage doesn't want to pass a value to
param
. With the later, the intention is less clear. The author of that code could've forgotten to pass the value. Or maybe the reader doesn't know about the existence ofparam
.While the
required
keyword exists, due to various constraints, it's not always possible to use it.For example, the source that is being worked on may be a package. In this scenario, marking all parameters as
required
would have undesired consequences on the users of the package (such as unnecessary breaking changes, or bothering users who don't like this practice).Similarly, not all code can be edited to have this
required
keyword, as some code may be coming from packages/SDK. A codebase using this lint would expect all parameters of said package/SDK to also be "required", yet the implementation wouldn't match that.Examples
Nothing special to say here. When this lint is enabled, both positional and named parameters would be required, even is marked as optional: