Really nice SL !

FXCop actually looks better than stylecop, and is more flexible. It does style as well as picking up potential issues. Until I read this thread, I thought that FXCop was depreciated and that StyleCop was the new FXCop - and I was wrong. I used FXCop a long time ago and it ROCKED. Why don't you suggest FXCop to the team.

If you're allowed to turn off rules you don't agree with, then this gives you the opportunity to set the coding standard for this pilot - which sounds like a fair amount of trust in your decisions :) The method/property/event ordered by access type sounds like something with little payoff vs grouping similar methods ec together. If you don't like it, and you're given the green light to work out which rules should be enforced, then just turn it off. Maybe if you are not sure about a rule, leave it on for a while and see if the resulting code ends up cleaner or easier for your teammates to quickly get up to speed with your code. Having to document every public method also sounds like overkill unless you are creating a library for third parties to use. Kent

You've had quite a few replies - some love StyleCop and some really don't like the need to code in a specific way. I actually understand both viewpoints. I once worked with a coder in the early 90's who was he was recommended as a guru by another company. One of the many personal coding styles he insisted on was that indentation was for wimps. He took every opportunity to rail at the request that he should indent (and many other equally silly things) - he was actually pleased that it made it harder to read, since then only the good developers would be able to understand the code. Good coders have their own styles. They quite often have strong opinions on style. They probably vary from the other good coders in the team. They also probably refactor each other's code to conform to their style. I think that good coders who work in teams need to play nicely with each other and part of this is to agree on a style and stick to that. It helps code readability and predictability for the team (once they are used to the style). This in turn reduces bugs and the cost of maintenance. Good coders write excellent code. Great coders leave a legacy that the rest of the team can keep in top condition. If this is going to be a large, mission critical project which can impact lives (Financial, emergency services etc) and have many team members thrown at the project, then maybe having a clean, well structured, easy to read and maintain codebase is important. Maybe also lower bugs and cost to maintain is also important. Maybe have a chat to your team about this. Or perhaps try it for a few months and see what you think after this time. Kent Cooooooooooooode

You are spot on Michael. However, there is no requirement to include the source code, so you can rebadge a BSD product, release the binaries and say that you developed it, with a small copyright notice somewhere in your documentation and/*or* somewhere else attributing some of the code to others (eg Help | about | licenses | Thanks). wikipedia tells it best: "The BSD License allows proprietary commercial use, and for the software released under the license to be incorporated into proprietary commercial products. Works based on the material may even be released under a proprietary license (but still must maintain the license requirements). Some notable examples of this are the use of BSD networking code in Microsoft products, and the use of numerous FreeBSD components in Mac OS X." Kent Bolton

BSD does allow exactly that. Part of the initial network stack in Microsoft Windows 95 was taken from a BSD licensed *nix. Most open source licenses do not. For instance GPL does not. Apache does not. CDDL does not. LGPL kind of can as long as it is a library and you distribute (or make available) the source of the library and the license. Other licenses require you only to acknowledge the source, send the writer a postcard, buy them a beer etc. Get a lawyer to let you know the ramifications if you are in doubt. Otherwise, don't use other people's code in a proprietory software development. The ramifications of infringement vary from private hand slapping, public shaming to law suits. Often in that order if you ignore reqests to remove the code. Kent Bolton