Properties that are explicit interface implementations are not sorted consistently

[jpj625]

Environment

• Visual Studio version: 2015 Enterprise Update 3
• CodeMaid version: 10.1
• Code language: C#

Description

Properties with the same name, some of which are explicit interface implementations, are not sorted consistently. This causes occasional merge issues when the properties are re-ordered in different ways in different branches.

Steps to recreate

1. Add attached file ClassWithInconsistentSorting.txt to a project (as .cs)
2. Apply Reorganize to the class ClassWithInconsistentSorting with "Alphabetize members of the same group" enabled

Current behavior

Same-named properties (allowed by explicit interface implementation) sort differently based on initial position.

Start

IProperty Property
AreaB.IPropertyHaver.Property
AreaA.ICoProduct.Property

Reorganize 1

IProperty Property
AreaA.ICoProduct.Property
AreaB.IPropertyHaver.Property

Reorganize 2

AreaB.IPropertyHaver.Property
AreaA.ICoProduct.Property
IProperty Property

Reorganize 3

AreaA.ICoProduct.Property
AreaB.IPropertyHaver.Property
IProperty Property

Expected behavior

Same-named properties should sort in a single, stable order.
Suggestion: Properties that are implicit implementations should be sorted first, with explicit implementations after, sorted by interface full name or other stable value.

[codecadwallader]

Thanks for reporting the issue and providing a code sample, I have reproduced it. I agree the reorganization order should be stable and not require multiple runs to get to that state.

[samcragg]

Hope I'm not hijacking with another feature request, but when implementing a fix would it be possible to have the option to have explicit interfaces methods/properties positioned after all public methods/properties - it might not be everyone's taste so that's why it would be good to have it optional?

[codecadwallader]

@samcragg Do you know if there is any standard for how explicit interface implementations should be treated? They are a bit of an oddball in that they don't have a declared access level but infer from their interface (if I remember correctly). I took a quick peek at StyleCop rules but didn't see anything listed.

[samcragg]

I don't think there's a standard - they just get treated as normal public properties/methods (there was an issue for the StyleCop analyser regarding this).

However, a personal preference (which I'm not alone with) is to have them after the end of the public stuff, i.e.

public MethodC
public MethodD
Interface.MethodB
internal MathodA

Like I said, it might be something that could be snuck in when fixing the ordering issue? If not I'd be happy to submit a pull request if you think the feature would be beneficial?

[codecadwallader]

Makes sense, thanks for the references. Pull requests absolutely welcome!

[codecadwallader]

@samcragg Is this still an issue following your pull request?

[samcragg]

I've been using the CI build (10.1.014) on my machine and it's been working fine for me, no issues with the order of the explicit interfaces.

I've just tried the reproduction steps and can verify that the two explicit interface properties are left in a consistent order when reorganising multiple times (the public one goes first then the two explicit interface properties are left in the order they were in the file, as they have the same name, however, they stay in that order and no longer "dance around" like reported)

[codecadwallader]

Awesome, thanks for confirming. I'll mark this as resolved to close out with the next release. :)