Finer-grained control of StyleCop-specific code cleanup

[stylecop]

Finer-grained control of StyleCop-specific code cleanup

[DoCode]

+1

[citizenmatt]

Not as it stands. The issue is that the code cleanup dialog isn't really intended to have all of the switches for all of the rules - there are over 150 rules, and while there aren't as many fixes in code cleanup, it still gets unwieldy to set them there.

My thinking in getting rid of these options in the dialog is why run code cleanup and not automatically fix everything we can? Does it make sense to clean up the code and still leave it failing?

What's your reasoning/use case here? Is it that the automatically created docs are not useful enough and you'd prefer to fix them yourself, or is something more generic?

For example, if the ReSharper plugin had an option just for docs (Add Default Comments, Add TODO Placeholders, Do Not Touch) would that solve the problem? Or is it something that needs to be applied to more rules (in which case some other UI needs to be thought about)?

[daviddunson]

The purpose for documentation is for another developer to understand what the type member does. Automatic documentation defeats this purpose. Adding default documentation for parameter-less constructors is OK; however, everything else must be addressed by the developer. Adding TODO might seem like an acceptable solution; but unless the developer goes looking for these entries, the work will never get done. I need SA1600 warnings to show up during the build to force the developers to address documentation before checking in their code.

[dmitriyse]

+5! This is must have feature (take it back into cleanup dialog). Some StyleCop cleanups works awfull and should be disabled, but corresponding rules should be enforced at build (command line check). I cannot migrate to R# 9.2 until this feature will be "re-implemented". P.S Thank you for giving new live to the StyleCop.

[citizenmatt]

I've separated out the code cleanup options into two - "Fix violations" and "create XML doc stubs". I still think the idea that if code cleanup can fix violations (spacing, ordering, missing this, missing brackets, etc.) then it should. There shouldn't really be any need for configuration - as long as the rule is enabled, the code should be reformatted to match.

But, I do think the argument for not creating XML doc stubs is a good one. Ordering and layout is one thing, but generating content is a bit much. So, XML doc stub creation is a separate option, disabled by default. (To be honest, I'm not a fan of the XML comment rules, especially when it comes to the default text it should start with - the text for the constructor summary is always the same, it doesn't tell us anything useful, why clutter up your code with it?)

Anyway, that's what I've done for now. Let me know what you think.