Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SA1300 misfires on members that implement interfaces #771

Closed
AArnott opened this issue May 4, 2015 · 5 comments · Fixed by #787
Closed

SA1300 misfires on members that implement interfaces #771

AArnott opened this issue May 4, 2015 · 5 comments · Fixed by #787
Assignees
Milestone

Comments

@AArnott
Copy link
Contributor

AArnott commented May 4, 2015

All rules that enforce naming conventions of members should not fire when the member provides an interface implementation.

The rule can and probably should fire on the member in its interface declaration, but not on its implementations. For instance:

On the interface, the rule may fire:

interface IVsCfg
{
    int get_DisplayName(out string name);
}

But don't blame the implementation of such a method:

class MyVsCfg : IVsCfg
{
    public int get_DisplayName(out string name)
    {
        name = null;
        return 0;
    }
}

Another example of a place to avoid reporting a diagnostic is explicit interface implementations:

class MyVsCfg : IVsCfg
{
    int IVsCfg.get_DisplayName(out string name)
    {
        name = null;
        return 0;
    }
}
@sharwell
Copy link
Member

sharwell commented May 4, 2015

I was thinking about this yesterday actually. I was thinking we could do this:

  1. Do not report a warning if the declaration uses override.
  2. Do not report a warning if the declaration explicitly implements an interface member.

However, I'm not sure we should make an exception for declarations that implicitly implement an interface member.

@AArnott
Copy link
Contributor Author

AArnott commented May 4, 2015

Adding override is a good idea.

I'm not sure we should make an exception for declarations that implicitly implement an interface member.

Why not? The compelling case for me happens frequently: the implementing class actually implements many interfaces (e.g. IVsCfg, IVsCfg2, IVsCfg3) and they all derive from their predecessor. So using explicit interface implementation syntax means I have to define an extra method for every interface rather than just making the method public and let the compiler implement all interfaces at once.

"But it's worth it," I can hear folks say "...because if you make it public that means the bad name is also visible to folks just using your class." Ya, and I would go for that too. Except the class itself is internal so it's a non-issue. It is only there to implement the interfaces and not to be exposed itself.

@pdelvo
Copy link
Member

pdelvo commented May 5, 2015

I have a look at this

@AArnott
Copy link
Contributor Author

AArnott commented May 7, 2015

One other reason I hit today---sometimes it's simply not an option at all to make it an explicit interface implementation. When an object is exposed to COM as an IDispatch object, the members must actually be public (not explicit interface implementation) or else IDispatch fails.

@sharwell sharwell added this to the 1.0.0 Alpha 7 milestone May 11, 2015
@AArnott
Copy link
Contributor Author

AArnott commented May 11, 2015

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants