Stylecopanalyzers: SA1201 - Any chance on specifing a custom order of elements???

[Hylndr]

Hello All,
I was curious if there is a chance to setup a way in which the users could specify the order of various elements??? We would like to enforce a defined order of elements, however, they are different than what is currently defined... I would like some was of designating the particular order that we have defined in our own coding standards. Right now we have to disable SA1201 or insert the suppressing statements in order to use this rule... The addition of the suppression statements in every class is a bit messy.

Thanks in advance,

Kevin Orcutt
Senior Software Engineer
Meyer Tool Company

[sharwell]

Yes, you can configure this in stylecop.json:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/Configuration.md#element-order

[Hylndr]

Well,
Thanks, but I don't think that will help us out any.. Let me be a bit more specific:
Current Ordering Rules per https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1201.md

States:
Within a class, struct, or interface, elements should be positioned in the following order:

Fields
Constructors
Finalizers (Destructors)
Delegates
Events
Enums
Interfaces
Properties
Indexers
Methods
Structs
Classes*

Within a class, we would like:
Enums
Fields
Properties
Commands
Delegates
Constructors and Finalizers
Events
Functions and Methods

...
So I don't see a way of specifying that level of ordering within the class level. Correct me if I'm wrong on that. It would be nice to set that.

Thanks again,

Kevin

[vweijsters]

That would be an extension indeed. Marking it with the appropriate tags.

[postb99]

Hi,

I noticed that our usual coding style also lists Fields, then Properties, then Constructors.

Any news on discussion on this enhancement?

Thanks

PS: we use StyleCop 1.1 beta because of .net core 2.2.

[NinthDesertDude]

I think variables and properties should come before the constructor. Here's my interpretation of both reasons:

Variable, Constructor, Property
Variables are all private, properties and methods that follow are part of the public interface. So this is about separating private and public interface.

Variable, Property, Constructor
Methods can be private and shouldn't be separated from other method definitions. Public static readonly variables can be useful. Variables and properties are viewed collectively as part of the state of the class, especially with auto-implemented properties. So this is about separating the state of the class from the methods (and whatever else).

Seems that both of these trains of thought are reasonable and valid enough to be supported.

[sharwell]

I was never particularly happy with the behavior of SA1201 as originally defined. In addition to various problems in attempting to support code fixes, the rule fails the "small diff test" (small changes to code should result in small diffs for source control). I don't believe that making this rule configurable will improve the maintainability of the product or help prevent bugs from occurring in the implementation of this rule. For now, let's keep the semi-highly-opinionated status of this rule and not expand its extensibility.

💡 Even though this rule is not configurable, a new Roslyn analyzer could be created to implement a different ordering rule. This project is intentionally licensed to allow other projects to borrow from its implementation strategies.

[postb99]

Thanks for your explanation. Most people either don't have time to implement custom analyzers or don't share them to others. So lambda users feel disappointed (I am one of them). Anyone can share its own ordering rule implementation and how to integrate it without wasting time/being victim of side-effects or maintenance problems?