This has nothing to do with my ego or the rules I like or dislike. It is about the rules that my
team have agreed upon. The correct style is not my style, it is not your style, it is not StyleCop default style. It is the style that a group of developers agree upon. What is important is that they write code that is consistent with their
agreed upon standard.
It seems that StyleCop's code principle:
StyleCop provides value by enforcing a common set of style rules for C# code. StyleCop will continue to ship with a single, consistent set of rules, with minimal rule configuration allowed. Developers can implement their own rules if they so choose.
doesn't sound like "tool for enforcing any style for every team".
However, as for me, personally I absolutely agree with you. I believe that there is nothing bad with more flexibility and often you really need to enforce your specific style, not the "worldwide" one.
And I consider StyleCop the best tool for doing this, using third-party or own-written rules (e.g.
StyleCop+ removes all barriers in naming constraints).
Paired rules lead to conflict. What if both UseStringEmptyForEmptyStrings and UseEmptyStringsForStringEmpty are enabled?
Doesn't seem to be a problem.
First, final StyleCop running usually takes place on build server, with settings specified by some "administrator" guy.
Second, you can make your rules to give warning about configuration conflict (I did such thing in
StyleCop+ - if you try to turn on extended original rules without turning off the original ones, you will immediately get a warning during analysing process).