These are chat archives for DotNetAnalyzers/StyleCopAnalyzers

15th
Nov 2015
Sam Harwell
@sharwell
Nov 15 2015 17:03
@/all What do y'all think about disabling all code fixes that are known to break down in some cases for the 1.0 stable release? In particular I'm thinking about all the code fixes which involve renaming files (including SA1412 which only renames files as a workaround for a Roslyn limitation).
Dennis Fischer
@pdelvo
Nov 15 2015 17:57
then you would have to disable all ordering fixes too. They can break if you have #ifs
Andrew Arnott
@AArnott
Nov 15 2015 19:32
If a code fix works most of the time, I'm in favor of keeping it available. Stable vs. unstable for a stylecop analyzer IMO would be based on whether it's likely to flag wrong things. Code fixes are the user's choice to run and to review its impact. But certainly code fixes that can cause subtle damage (the kind that might go unnoticed) it more than rare corner cases should perhaps be turned off.
Just my opinion. Feel free to disregard.
Sam Harwell
@sharwell
Nov 15 2015 19:49
Downside is many people put quite a bit of work into the code fixes which fall into this category, and in many cases they are useful. Upside is if we disable them, users who are apprehensive about adopting automation out of concerns about negative consequences when it changes code would be more likely to adopt our stable release.
Olly Atkins
@oatkins
Nov 15 2015 20:38
I agree with @pdelvo. If I have weird code that uses #if directives (I do), I would expect to have to review the results of an automated code fix. I'd still like to be able to use that fix on all he other files where it works just fine.