Fix Resharper settings to remove redundant hints & warnings

[philippdolder]

No description provided.

[jimmyheaddon]

Having performed this configuration many times in the past, I'd highlight that ReSharper's concept of configuration layers means we'll struggle to create a lightweight configuration for the solution which adequately overrides all users machine level settings, not without some decent effort and testing.

It's not insurmountable by any means, but it's never easy to get the configuration spot-on when working outside of a single team environment.

[jimmyheaddon]

This is a much wider point on static analysis, but I suggest we split this issue up:

StyleCop

1. Update the StyleCop.MSBuild NuGet package and fix the outstanding StyleCop violations
2. Review the use of StyleCop suppressions in code (if applicable)
3. Discuss the enforcement of StyleCop (using 'Treat warnings as errors' in .csproj files)

ReSharper

1. Create the FakeItEasy.sln.DotSettings file, and mirror Settings.StyleCop only
2. Review the use of ReSharper suppressions in code
3. Amend the FakeItEasy.sln.DotSettings as per comments in add CONTRIBUTING.md #36

Code Analysis

1. Review the use of Code Analysis and #pragma suppressions in code
2. Review the 3 rulesets in the solution and the severity of rules
3. Discuss the application of FakeItEasy.ruleset to projects (FakeItEasy.csproj is configured to use this, but Code Analysis is disabled for all build configurations)
4. Discuss the enforcement of Code Analysis in builds
5. Discuss the integration of Visual Studio 2015 analysis rules (changes with Roslyn)

Misc Analysis

1. Review outstanding build warnings - whether they should be addressed and whether 'Warnings as Errors' should be enabled
2. Review the various Roslyn analyser results

[adamralph]

@jimmyheaddon thanks for chiming in. As you suggest we should split these up. This issue can be the "Resharper" part of your comment. The other bits can be other issues/PR's.

[adamralph]

Since dumping Resharper from my toolkit for the second time, I'm once again shying away from this. The ubiquitous static analysis solution is promising to be Roslyn based analysers and I think we should lean on them for code consistency using whatever mechanisms they provide for rule customisation.

Resharper is a personal tooling choice and if it doesn't respect Roslyn analyser settings then it should be made to do so, using whatever extensions, etc. are required.

[blairconrad]

@adamralph, I'm not sure I understand what you're saying. I think you're coming down on closing this...
does

if [ReSharper] doesn't respect Roslyn analyser settings then it should be made to do so, using whatever extensions, etc. are required.

mean "… without any changes to the FakeItEasy codebase"?

Like I should run off and update my personal settings and get extensions in order to comply?

I don't mind doing this. In fact, I have been. (Or ignoring the odd warning from ReSharper, because I am familiar enough with FIE's settings.)

[adamralph]

(Feel free to substitute "R#" in the following for the refactoring/static analysis tool(s) of your choice.)

For example, we currently use StyleCop and have a Settings.StyleCop file to define our settings. R# should have some kind of facility to respect that settings file.

StyleCop is in its death throes (although there are current efforts at salvation) but long term I don't see it winning out against Roslyn analysers. StyleCopAnalyzers looks like it may be the solution going forward and, again, R# should have the facility to respect the settings that come along with them (whether built in or via extensions). If R# doesn't have a nice way to play along with Roslyn analysers then I predict its demise.

As a maintainer who doesn't use R#, I don't want the burden of (somehow) maintaining a settings file for it. However, I'm only one of two maintainers. If I'm outvoted and the other two maintainers are users of R# and are happy to maintain a settings file for it then I'll happily go with the majority.

[blairconrad]

Oh, I don't think we should outvote anyone—much better to come to a consensus. I'd hate for someone to go away feeling like they were forced into anything.

The only reason I'd consider moving forward with this issue is that even though ReSharper isn't universal, I believe it to be quite popular, and I experienced the (minor) frustration of having it try to take away all the this.es in the code, and the like. I'm moderately happy with my personal solution settings file, so don't see many problems, especially after @thomaslevesque pointed out the "keep fully-qualified usings inside a namespace" setting the other day.

Certainly in the short term, I'd be more than happy to muck about with a ReSharper settings file for the solution. But I'd have no objection to removing such a settings file once it became onerous, for example, if it started fighting with our preferred settings and nobody on the team had interest in working on it.

[adamralph]

Isn't there a StyleCop extension for Resharper which will use the Settings.StyleCop file?

[blairconrad]

Could be. You're suggesting giving ReSharper users the advice to pick that up instead of us maintaining a dotsettings file?

[adamralph]

I'd certainly prefer it.

[blairconrad]

Works for me. @thomaslevesque, you're okay with this being closed as a wont-fix?

[thomaslevesque]

Sure, i don't mind. I can always have my own per-user R# settings anyway ;)

[adamralph]

Do you want to confirm that you can indeed point R# at the StyleCop.Settings file?

[blairconrad]

For me, and for @thomaslevesque it sound, nah. I'm okay with a personal file.
If some community contributor runs into difficulty, we can examine the situation at that point and see what's best. Maybe everything will be fine and ReSharper will start natively paying attention. Or whatever maybe the extension stops working we'll just share an appropriate dotsettings file.
Let's not buy trouble.

[blairconrad]

competing label updates…

[thomaslevesque]

Just tried the StyleCop R# extension, it seems to work fine.

[adamralph]

@thomaslevesque great, so if anyone comes knocking on this door again, we can just point them at that.