Welcome to the Lounge

OriginalGriff wrote:

Am I on Candid Camera or something?

Jarek Kruza wrote:

I hope your wife's name is Mary

if(   check_func(a,b, c ,d)) {
   process(long_Name ); }

else if ( verifyFUNC(  zzz))
{
         discard( shrtNme);
}

Hmm, Super Lloyd I think you nailed it on the head in that you don’t want to be bothered with style issues so StyleCop may be seen as just an impediment. Nothing wrong with that. StyleCop certainly takes a lot of getting used to and if the benefits of its use won’t be realized, well, just like anything else, probably best not to go down that path.

We started using StyleCop 5 years ago in one project and moved to use it in all of our in-development C# projects, ~70. Prior to its usage, styles varied wildly and conflicted making for a difficult to read, modify and navigate code base. We've gone from a team of 5 developers up to 12 and now to 4.

A few notes:
1.  It is not that StyleCop rules are always right, it’s the fact that they are always enforced that, IMHO, is the big win. Ever have to listen to, or explain about style in a code review? Tool usage might be easier. – megaadam mentioned this as well.
2.  Enforcing that StyleCop warnings are errors or turn them all the way off to avoid spewing warnings that never get fixed.
3.  Understand that it takes quite a while to get used to the level of checking. It took me about 6 months but around then I just stopped doing things that would cause errors, same thing goes with Code Analysis.
4.  Some team members had to give up the idea that their code style was part of who they were or how they expressed themselves. Once they got over that, they were the biggest proponents of the tool.
5.  The <inheritdoc/> tag can be used when implementing overrides where the base class documentation is sufficient to avoid duplication.
6.  The <include file='....'/> tag can be used for documentation that would otherwise have been copied and pasted.
7.  A CustomDictionary.xml can be used to inform StyleCop of naming overrides.
8.  The argument that things should be placed next other things which are most related works great until it doesn’t. For example, two methods or properties that use the same field – where should the field be located?
9.  I don’t know what you are referring to when talking about #regions begin required around using statements. #region’s and StyleCop don’t get along together well and most of our code base does not use #region’s. The only requirement I know of is the ordering and placement of namespace using statements; they must be within the enclosing namespace and grouped and order by name.