SA1600 should not trigger for explicit interface implementations about stylecopanalyzers HOT 7 OPEN

@Alxandr Not the same problem. Yours is a duplicate of #3595 which has been fixed but not yet released.

from stylecopanalyzers.

IMO, no. I think SA1600 should not apply to explicit interface implementations. But the rest (assuming they only run when documentation is present) should run. The high level is: docs aren't required, but if they exist, they should follow the regular rules.

Thanks for the input! The connections between the rules are intricate and my thinking might be flawed, but this is my take on it:

That would mean that SA1615 would require a return tag for a method if there is any documentation at all. For private members, that is not required by default. I don't think we should put higher demands on explicitly implemented members than on private ones, rather the contrary since explicit ones can never be used directly.

I definitely agree with you on rules that trigger on bad or missing text inside a tag (for example SA1616 for the returns tag), but those are other rules than the ones I listed above. (SA1611 looks suspicious though, I will have to check that one again.)

from stylecopanalyzers.

I am having a look at this. There seems to be quite a lot of dependencies between the SA16xx rules at the code level, with many of them calling a method inside the SA1600 analyzer. I need to try this out some more, but my gut says that this is not the only rule that should be affected by this issue. What is actually the desired behaviour? Should we treat explicitly implemented methods etc as if they were private or skip them all together? I am for example thinking about how the "document private elements" option fits in this.

from stylecopanalyzers.

Thanks for looking, @bjornhellander.
I think the doc rules should allow for the user not documenting explicit interface implementations. But if they are present, the rules that ensure that docs follow certain conventions are probably still good to run. For example, if I did document the method (for whatever reason) but left out the docs for one particular parameter, or put them out of order, then stylecop calling that out is arguably still a good thing.

from stylecopanalyzers.

SA1648 has the same issue. I get an error telling me that I can't use inheritdoc when doing static TAggregate IAggregate<TAggregate, TEvent>.New(Guid id). Not sure if this qualifies as a new issue or not.

from stylecopanalyzers.

The following rules share code today that determine if the rule is applicable for a specific element, based on accessibility and documentation settings:

• SA1600 ElementsMustBeDocumented
• SA1601 PartialElementsMustBeDocumented
• SA1602 EnumerationItemsMustBeDocumented (not relevant for this discussion)
• SA1604 ElementDocumentationMustHaveSummary
• SA1605 PartialElementDocumentationMustHaveSummary
• SA1609 PropertyDocumentationMustHaveValue
• SA1611 PropertyDocumentationMustHaveValueText
• SA1612 ElementParameterDocumentationMustMatchElementParameters
• SA1615 ElementReturnValueMustBeDocumented
• SA1618 GenericTypeParametersMustBeDocumented
• SA1619 GenericTypeParametersMustBeDocumentedPartialClass

So for example if the element is private and it is not configured that private elements should be documented, then SA1600 does not trigger, but it also means that none of the other trigger, which they would have done by default if the element had been public.

Is the intended behaviour that none of the above should ever trigger for explicitly implemented members, regardless of documentation settings?

from stylecopanalyzers.

Is the intended behaviour that none of the above should ever trigger for explicitly implemented members, regardless of documentation settings?

IMO, no. I think SA1600 should not apply to explicit interface implementations. But the rest (assuming they only run when documentation is present) should run. The high level is: docs aren't required, but if they exist, they should follow the regular rules.

from stylecopanalyzers.