How did your team customize Stylecop (and perhaps other tools) for .Net for a good result?

Our team is still in a love / hate relationship with it. I am hoping to put an end to the debate by having an internal vote on what rules should be excluded and which rules should be added.

Before doing so, I wanted to 开发者_Python百科ask others SO users. To standardize (but not limit) the responses:

1. What is your current StyleCop version?
2. What .Net version do you currently target?
3. Which default rules did you turn off?
4. Which non-default rules have you turned on?
5. Have you coded your own rules? Please describe.
6. Do you have any other StyleCop tricks worth sharing?
7. Do you use Resharper? What version? Is it a good bang for the buck?
8. Do you use any other tools for .Net / C++ which integrate with Visual Studio and aid development? Did you get your money's worth?
9. Anything else you like to add?
10. ...

Thank you!

1. What is your current StyleCop version? 4.3.3 locally, 4.3.0 on build server
2. What .Net version do you currently target? 2.0 or 3.5
3. Which default rules did you turn off? none
4. Which non-default rules have you turned on? just added a couple of exclusions to the Hungarian rule
5. Have you coded your own rules? Please describe. nope
6. Do you have any other StyleCop tricks worth sharing? use the <ExcludeFromStyleCop> element in your project files
7. Do you use Resharper? What version? Is it a good bang for the buck? yes, R# 5, great value (especially with StyleCop for ReSharper)
8. Do you use any other tools for .Net / C++ which integrate with Visual Studio and aid development? Did you get your money's worth? GhostDoc is the only other tool we use

1. I'm on 4.3.3.0
2. .net 3.5
3. Lots, all the Documentation and a collection of others.
4. None, IIRC.
5. In the past I did. I currently have no coding style requirements, but previously I did. I create custom rules for them when I have them.
6. "Right-click the warning, Show Error Help" is a good one. My favourite is "add the Settings.StyleCop file to the Solution Items folder".
7. No, but I would if I could.
8. FxCop. Yup, infinite value for the money.
9. Yes. What rules you enable/disable should be driven entirely by the coding guidelines that you're trying to validate against. The reason you don't know which ones to use is likely because you don't have any. So that's the first thing you should be doing, creating a set of coding guidelines. You could use StyleCop to determine which rules you want to enforce (start with all of them on and remove one when everyone agrees that that rule provides no value for the effort it would take to fix it). That seems a little backward and would skip the possibility of having a coding standard that wasn't already enforced by StyleCop, but is definitely better than nothing. And it would be a quick way to generate some local standards. Another way to do it would be to look around for some existing published coding guidelines that your team can more-or-less agree on(1) and then configuring StyleCop to enforce those. Either way, there's a lot to be gained from having a consistent coding style across the group, and StyleCop's the way to go to enforce it.
10. Custom rules are awesome. Don't discount the possibility of turning off a StyleCop rule and implementing a 'better' version of the same rule.

(1) It's like pizza toppings, there's no way you'll get complete agreement in the group but a general consensus can arise

1. 4.3.3
2. .NET 3.5
3. Turned off SA1309 - FieldNames must not start with underscore (for private variables behind a Property
4. custom rule that no variables start with "m_"
5. Yes, custom rule in #4 based off of code in this blog
6. not really
7. no
8. we use the VisualSVN plugin, it's free and we find it useful since we use Subversion for source control