Should documentation be added for constructor parameters that are passed via dependency injection? In my current project I have decided to omit documentation to describe each of these parameters and my reasoning for this is as follows:
These constructors are not meant to be called by a developer (outside of unit testing, but I will only be using integration testing in this project) so why bother documenting the parameters passed to them? The parameters are passed by a DI framework, which isn't going to read the documentation when constructing these classes.
Many of the services being injected are singletons. By adding parameter documentation for every constructor to which they are injecting, I'm adding a bunch of duplicate documentation all over the project. Now, if the semantics of how that service is used changes later, I will have to update the comments in every constructor. It seems like a better solution for the developer to just go look at the class documentation for the service.
Is this reasoning sound? Are there any reasons you would disagree with my rationale for excluding these comments? Are there potential benefits of including these comments that I have overlooked?
To add some further context to this question, these are XML comments in C# that will eventually also be used to generate documentation for the project. I am in the process of integrating StyleCop into the project which has a rule to make sure that all function arguments are documented. So this issue arose because I am being forced to choose between documenting these parameters or suppressing the warning messages for each constructor using injection. I do not want to disable the rule globally because I do want to ensure that parameters for regular methods and constructors are documented.