It affects the issue I'm working on: #32

Should I use a Hidden diagnostic instead of a Refactoring?

That depends strongly on the instance we're willing to let Code Cracker take in regard to the code being analyzed.

It seems to me that being Hidden is much more alligned to the directions we want the project to follow: we are not trying to create an invasive tool, instead I think we want it to leverage good practices and common code issues that may run unadvisedly in the day by day rhythm of the common developer. This way, while most issues would be considered Hidden, maybe we might have a few cases where Information or Warning are present.

Does that make sense?

@marcellalves I don't know. If we decide we should prefer Hidden diagnostics + code fix, maybe.

A little bit more info:

I just tested and a refactoring will only run when ask for it. While an analyzer always run when there is a new compilation, what happens all the time when the user is typing on Visual Studio. So analyzers take up more CPU cycles. Way more.

Both can be accessed via Ctrl+Dot.

There are two main differences:

1. Refactorings can operate on TextSpans (the user's selection), so they can take the user's intent to change a certain piece of text into account.
2. Refactorings don't show the lightbulb automatically. Reserve diagnostics for things that you believe are definitely an improvement, whereas refactorings are somewhat aribitrary changes where it takes the user's judgement to decide if it's better or not. For example, something like "invert-if" should be a refactoring, because the user has to decide which way is better. You don't want to constantly have the lightbulb in their face suggesting that they change it.

That's the intention, anyway.

Oh, and so as it applies to Issue #65, I would leave it as a refactoring.

@Pilchie, only analyzers/fixes can be deployed as NuGet packages, right?

As @viniciushana says, if the intent is to advise and help with best practices, I think analyzers/fixes are the best option.

But between hidden analyzers and refactorings is ah hard choice to make. One that might impact the performance and usability of VS.

One that I think could be an analyzer/fix is making a type that has disposable fields implement IDisposable and dispose of those fields. It's something that you need to make a conscientious choice but, if in one had it's not an error, on the other hand it might be overlooked and the lightbulb would be helpful.

@Pilchie @paulomorgado Refactoring can't be deployed as Nuget Packages! Right! This is a HUGE difference. @code-cracker/owners we have to discuss this more deeply. It is a considerable impact on how we are thinking about this project deliverable.

@paulomorgado @giggio It's true that refactorings can't be deployed in NuGet packages right now, but that is something we're thinking about changing in the long term (possibly not in time for VS 2015 though).

So, is the intent that refactorings be machine wide (vsix) while diagnostics (not hidden) be used to encourage/enforce project expectations?

Are NuGet analyzers (hidden or otherwise) always project specific?

Is this the best place to discuss this?

Hard but very good questions, @KathleenDollard.

Personally, I don't really see the value of distributing CC in a NuGet package. I think it makes more sense to distribute it in a vsix package, thus allowing some nice stuff like choosing which analyzers you want to use, for instance. Sometimes I think that Resharper itself has some solutions to those kind of situations and I see CC walking towards similar paths.

@KathleenDollard the long term intent is that you can also package refactorings in NuGets, because we believe that like diagnostics, there are domain specific refactorings that should be packaged with an API. We just haven't done that work yet.

NuGet Analyzers today are always project specific, because the way they work is to add a command line option to the compiler invocation to run that analyzer as part of the compilation.

Feel free to nominate a better place to discuss this (a CodePlex forum maybe)?

I tend to agree with @Pilchie on this one. We had a similar discussion on DotnetAnalyzers, and we landed in almost the same place: CodeFixes should be finding practices that will likely lead to errors. Refactors are more about structure and style. (Lots of comments in the area of StyleCop: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues)

@viniciushana you can very much select which analyzers you want when you use Nuget:

Please see #47 where we discuss exactly that.

@Pilchie good to know that allowing refactorings to be deployed as nuget pkgs are in the roadmap. It would be very welcome, for the exact reasons you stated.

We still need to discuss this more deeply. I will call for a meeting with the core team and anyone who wishes to participate. If anyone in this thread (or who is reading this) is interested please let us know.

@Pilchie are there perf issues? I imagine that "hidden analyzers" would be run pre-emptively on the entire solution, but refactorings would only be run on-demand when you do ctrl+dot ?

IIRC, hidden diagnostics are only run on open files, even if the option to run diagnostics on closed files is checked.

@giggio I would be really interested to discuss about that.
I was pretty much for the Hidden analyzers in my own code as it's mostly what ReSharper does.

Not surfacing any UX (LightBulb) for something that the user might want to do is a pretty bad practice (ReSharper underline info level, show small dotted underline of 1 character for a Hint level under that who doesn't exists in Roslyn and lot of their convenience refactorings show the lightbulb as they are hidden "analyzers")

Ok, we discussed this in person just now. We decided that, right now, we won't work on refactorings unless it is something we can't do with a Hidden diagnostics, so almost all refactorings will be diagnostics. Only when the users is selecting a text span and wants to perform as specific action we will do refactorings.
Not being able to ship refactorings with Nuget influenced the decision. Always showing the light-bulb too. We don't feel users will be annoyed by the light-bulb, on the opposite, they want to know that there is something that they can act on. If this changes and we get a different feedback we will review this item.
Thanks for everyone who collaborated.