Should parameter name change rules be removed?

[tomzx]

In all of the cases, a parameter name change generates a PATCH increment. Furthermore, changing a parameter name will also most likely imply method implementation changes as well which are also PATCH increment. Thus, those rules are most likely only generating noise, that is information that is not very interesting. Finally, it is generally of no interest to the callers/client code if a parameter name has changed.

Affected rules
V060 - Class public method parameter name changed
V061 - Class protected method parameter name changed
V062 - Class private method parameter name changed
V063 - Interface method parameter name changed
V064 - Trait public method parameter name changed
V065 - Trait protected method parameter name changed
V066 - Trait private method parameter name changed

Thus, I suggest the removal of the mentioned rules from the ruleset.

[mikeSimonson]

Is it possible to keep them but not enable them in the default build ?

[tomzx]

That could be an alternative, but then that would open the door to having other rules not available in the default build... I wouldn't mind as long as they're adding value to the overall tool.

What value do you see in keeping those rules available?

[mikeSimonson]

Maybe sometimes some people analysing the change of an api will want to know about the parameter name change just because there isn't any other change and it might improve their overall comprehension of the api they are using.

Or maybe you should get rid of it and not look back. I just wouldnl't reuse those rule numbers to avoid confusion.

[tomzx]

Rule number reuse is certainly out of the question. It is basically the main reason they're there to begin with: unique identifiers.

Thanks for your feedback!