StyleCopRules

StyleCop settings intended to help rather than harm your project.

Introduction

Used correctly, StyleCop is a useful tool for enforcing healthy code hygiene in your C# project. Used incorrectly, it can cause considerable harm by prompting developers to resort to bad practices like autogenerating documentation or wasting the developers' time by forcing them to manually keep their code elements sorted.

StyleCop should be gentle and almost invisible rather than intrusive. It should get out of the developers' way, yet keep them from writing sloppy code by accident. Therefore, there is little room for rules that generate false positives. In general, a candidate rule needs to provide benefits that significantly offset the cost for developers in order to be included in the analysis. When in doubt, it is better to leave a rule out.

This project contains my subjective assessment of the available StyleCop rules, as well as a settings file that corresponds to the assessment.

Disclaimer

Hopefully this is obvious, but still: I wish to make it very clear that I appreciate the effort put into making StyleCop, which is a useful tool that aids quality-minded .NET developers all over the world every day. While I make some opinionated assessments of some of the rules below, it doesn't mean I think poorly of the good people behind the tool. Quite contrary, I wouldn't be making this assessment if I didn't think StyleCop is an excellent tool worth spending time on - I just want to maximize the benefit I get from it. Moreover, this is obviously a single developer's opinions, based on subjective experiences and the specific contexts I've worked in. Your milage may and will vary.

Assessment of rules

Documentation Rules (SA1600-)

I think it's a very bad idea to use a static analysis tool to mandate documentation of all code elements. It inevitably leads to very low-quality documentation. The only reason I can think for doing so is that it leads to high documentation coverage. However, measuring documentation coverage is a completely meaningless exercise because it is easy - trivial - to autogenerate documentation (using ReSharper, GhostDoc or what have you). Autogenerated documentation is worthless. In fact, it's even worse than that: it has negative value. Autogenerated documentation is a source of noise that leads to code that is less readable and makes it harder to find genuine documentation in the code base.

See http://www.stylecop.com/docs/Documentation%20Rules.html

Sane

• SA1603: DocumentationMustContainValidXml

  There is no reason to ever accept invalid XML.

• SA1604: ElementDocumentationMustHaveSummary

  I can't think of any meaningful exceptions to this rule - provided you have a documentation element, it should have a summary.

• SA1608: ElementDocumentationMustNotHaveDefaultSummary

  Obvious and admirable! A shame that so many of the other StyleCop rules for documentation invite developers to commit the exact same sin by turning to autogenerated documentation to fulfill a meaningless demand.

• SA1610: PropertyDocumentationMustHaveValueText

  Empty documentation is always nonsensical (but please don't ever resort to documenting the value of the property, ref SA1609 which is utterly insane - in other words, please render this rule superfluous).

• SA1613: ElementParameterDocumentationMustDeclareParameterName

  This is meaningful granted that you're documenting a parameter.

• SA1614: ElementParameterDocumentationMustHaveText

  Empty documentation is always nonsensical.

• SA1616: ElementReturnValueDocumentationMustHaveValue

  This is fine, an empty return tag makes no sense.

• SA1617: VoidReturnValueMustNotBeDocumented

  Sure, this is flagging an error.

• SA1620: GenericTypeParameterDocumentationMustMatchTypeParameters

  I suppose this makes sense given that the developer has come up with meaningful documentation for the type parameters (but ref SA1618 in the Insane category).

• SA1621: GenericTypeParameterDocumentationMustDeclareParameterName

  Ref SA1620.

• SA1622: GenericTypeParameterDocumentationMustHaveText

  Ref SA1620.

• SA1625: ElementDocumentationMustNotBeCopiedAndPasted

  Under serious doubt. Silly to check for, yet hard to envision meaningful duplicate comments. I suppose duplicate comments (due to copy-and-paste) will only happen if the project runs a static analysis tool that requires all code elements to be documented.

• SA1626: SingleLineCommentsMustNotUseDocumentationStyleSlashes

  This is OK, no need to use triple-slash for regular code comments.

• SA1627: DocumentationTextMustNotBeEmpty

  It makes no sense for the documentation text to be empty - in that case the entire documentation of the element should be deleted.

• SA1644: DocumentationHeadersMustNotContainBlankLines

  Ambivalent. A bit silly, but fair enough.

• SA1645: IncludedDocumentationFileDoesNotExist

  In case include is used the file should clearly exist.

• SA1646: IncludedDocumentationXPathDoesNotExist

  Similar to SA1645.

• SA1647: IncludeNodeDoesNotContainValidFileAndPath

  Similar to SA1645.

• SA1648: InheritDocMustBeUsedWithInheritingClass

  I've never seen this tag used, but I suppose it's fine.

Insane

• SA1600: ElementsMustBeDocumented

  No, I don't think they must. Mandatory documentation of all code elements inevitably leads to autogeneration of documentation based on the code elements themselves - hence the documentation can obviously not tell you anything not already in the code, obviating the need for the documentation in the first place. The result is "undocumentation" that clutters the code and harms readability.

• SA1601: PartialElementsMustBeDocumented

  Ref SA1600.

• SA1602: EnumerationItemsMustBeDocumented

  The StyleCop documentation for this rule nicely illustrates the type of meaningless undocumentation you incur on your code base when this rule is enabled. "Dog: Represents a dog."

• SA1605: PartialElementDocumentationMustHaveSummary

  I see no reason for applying this rule.

• SA1609: PropertyDocumentationMustHaveValue

  Reading the StyleCop documentation for this rule is sufficient to realize it is nonsense. What you possibly write that is not already covered by the name of the property or the summary description? The documentation of the value is doomed to become a hollow echo of the two.

• SA1611: ElementParametersMustBeDocumented

  While you may sometimes wish to document parameters, it is often not necessary, in particular if the parameter is given a meaningful name. If made mandatory, developers will tend to autogenerate documentation of parameters, resulting in documentation like the following:

  <param name="profileName">The profile name</param>

  How does this aid code comprehension in any way?

• SA1612: ElementParameterDocumentationMustMatchElementParameters

  This is a silly rule that means you must either document all the parameters or not at all. The developer should be free to document exactly the parameters that need documentation.

• SA1615: ElementReturnValueMustBeDocumented

  While you may sometimes wish to document the return value, it is often not not necessary. If made mandatory, developers will tend to autogenerate documentation of the return value, yielding documentation like the following, which is thoroughly unhelpful:

  <returns>The <see cref="Foo">.</returns>

  How does this aid code comprehension in any way?

• SA1618: GenericTypeParametersMustBeDocumented

  I'm struggling to come up with a scenario where you may say something about the generic type parameter besides the obvious fact that it is a generic type parameter (which is the example given in the StyleCop documentation). And of course that's completely redundant and silly.

• SA1619: GenericTypeParametersMustBeDocumentedPartialClass

  Ref SA1618.

• SA1623: PropertySummaryDocumentationMustMatchAccessors

  Completely absurd. We know what properties are and what they do. If we need documentation for a property, we would like to know why it is there - what the purpose is.

• SA1624: PropertySummaryDocumentationMustOmitSetAccessorWithRestricedAccess

  Huh? If you want to document a property setter of course you should be able to, regardless of access modifier. It would be equally meaningful to prohibit the documentation of private methods.

• SA1628: DocumentationTextMustBeginWithACapitalLetter

  My experience is that this leads to more false than real positives.

• SA1629: DocumentationTextMustEndWithAPeriod

  My experience is that this leads to more false than real positives.

• SA1630: DocumentationTextMustContainWhitespace

  I see no reason to check for this.

• SA1631: DocumentationTextMustMeetCharacterPercentage

  How do you even come up with rules like this?

• SA1632: DocumentationTextMustMeetMinimumCharacterLength

  This is meaningless. Encourage your developers to write meaningful documentation.

• SA1633: FileMustHaveHeader

  WAT?

• SA1634: FileHeaderMustShowCopyright

  HAHAHAHAH!

• SA1635: FileHeaderMustHaveCopyrightText

  Stop it.

• SA1636: FileHeaderCopyrightTextMustMatch

  This is pure trolling.

• SA1637: FileHeaderMustContainFileName

  Meaningless.

• SA1638: FileHeaderFileNameDocumentationMustMatchFileName

  If SA1637 is enabled, yes, but it's not.

• SA1639: FileHeaderMustHaveSummary

  But there is no file header. There shouldn't be one.

• SA1640: FileHeaderMustHaveValidCompanyText

  Meaningless.

• SA1641: FileHeaderCompanyNameTextMustMatch

  Meaningless.

• SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText

  This may be the most stupid rule of them all. Standard documentation stating that a constructor creates a new instance of a class? Thank you.

• SA1643: DestructorSummaryDocumentationMustBeginWithStandardText

  As stupid as SA1642, but less impact since destructors are scarce.

• SA1649: FileHeaderFileNameDocumentationMustMatchTypeName

  But there is still no file header.

• SA1650: ElementDocumentationMustBeSpelledCorrectly

  A factory for producing false positives. It's not worth the effort to have developers spend their time maintaining a dictionary to have StyleCop close down that factory.

Layout Rules (SA1500-)

I think it's OK to follow some layout rules, to the extent they help the project avoiding code that is simply sloppily written.

See http://www.stylecop.com/docs/Layout%20Rules.html

Sane

• SA1500: CurlyBracketsForMultiLineStatementsMustNotShareLine

  Ambivalent, on occasion it makes sense to have empty curly brackets on a single line.

• SA1503: CurlyBracketsMustNotBeOmitted

  Optional curly brackets should not be optional.

• SA1505: OpeningCurlyBracketsMustNotBeFollowedByBlankLine

  This is just proper code hygiene.

• SA1506: ElementDocumentationHeadersMustNotBeFollowedByBlankLine

  This is just proper code hygiene.

• SA1507: CodeMustNotContainMultipleBlankLinesInARow

  This is just proper code hygiene.

• SA1508: ClosingCurlyBracketsMustNotBePrecededByBlankLine

  This is just proper code hygiene.

• SA1509: OpeningCurlyBracketsMustNotBePrecedededByBlankLine

  This is just proper code hygiene.

• SA1510: ChainedStatementBlocksMustNotBePrecededByBlankLine

  This is just proper code hygiene.

• SA1511: WhileDoFooterMustNotBePrecededByBlankLine

  This is just proper code hygiene (although I've never seen this violated).

• SA1513: ClosingCurlyBracketMustBeFollowedByBlankLine

  This is just proper code hygiene.

• SA1514: ElementDocumentationHeaderMustBePrecededByBlankLine

  This is just proper code hygiene (and may actually occur in practice).

• SA1516: ElementsMustBeSeparatedByBlankLine

  This is just proper code hygiene.

• SA1517: CodeMustNotContainBlankLinesAtStartOfFile

  This is just proper code hygiene.

• SA1518: CodeMustNotContainBlankLinesAtEndOfFile

  This is just proper code hygiene.

Insane

• SA1501: StatementMustNotBeOnSingleLine

  IMHO the code is sometimes more readable on a single line. YMMV.

• SA1502: ElementMustNotBeOnSingleLine

  Sometimes being concise helps readability.

• SA1504: AllAccessorMustBeMultiLineOrSingleLine

  Only makes sense if you only ever have trivial property implementation (in which case - heresy! - you might as well have used fields instead, even though .NET lore indicates that this is very bad, m'kay?). It may well be that one accessor (e.g. get) is very simple whereas the other one is more complex.

• SA1512: SingleLineCommentsMustNotBeFollowedByBlankLine

  I don't quite see the problem and would rather be a bit too permissive than needlessly strict - I wouldn't want to break the build over this.

• SA1515: SingleLineCommentMustBePrecededByBlankLine

  Ref SA1512.

Maintainability Rules (SA1400-)

To claim that these rules vastly improves maintainability is probably stretching it, but they don't put any heavy burdens on the developer either. The false positive ratio will probably be very low.

See http://www.stylecop.com/docs/Maintainability%20Rules.html

Sane

• SA1119: StatementMustNotUseUnnecessaryParenthesis

  Probably just proper code hygiene.

• SA1400: AccessModifierMustBeDeclared

  It's probably a good idea to be explicit, but I don't feel strongly about this.

• SA1401: FieldsMustBePrivate

  Under severe doubt. This is an etablished "best practice" in the .NET world, but how many developers can provide coherent rationale for this best practice?

• SA1402: FileMayOnlyContainASingleClass

  This is the norm, a reader would be very surprised otherwise.

• SA1403: FileMayOnlyContainASingleNamespace

  This is the norm, a reader would be very surprised otherwise.

• SA1404: CodeAnalysisSuppressionMustHaveJustification

  It's probably always a good idea to provide a reason for suppressing a rule. (If the reason is "the rule is stupid", obviously the rule should be switched off.)

• SA1405: DebugAssertMustProvideMessageText

  It's probably always a good idea to provide a message; one can only hope that the developer will bother to write a meaningful one. Luckily I think ReSharper is not yet autogenerating such messages!

• SA1406: DebugFailMustProvideMessageText

  Ref SA1405.

• SA1407: ArithmeticExpressionsMustDeclarePrecedence

  This improves readability.

• SA1408: ConditionalExpressionsMustDeclarePrecendence

  This improves readability.

• SA1409: RemoveUnnecessaryCode

  Can't think of a reason to allow "empty" code like this.

• SA1410: RemoveDelegateParenthesisWhenPossible

  Uncertain. This is not important.

• SA1411: AttributeConstructorMustNotUseUnnecessaryParenthesis

  Uncertain. This is not important.

Naming Rules (SA1300-)

It pretty limited what a purely syntactic analysis tell us about the quality of names.

See http://www.stylecop.com/docs/Naming%20Rules.html

Sane

• SA1300: ElementMustBeginWithUpperCaseLetter

  Fair enough, it's the convention.

• SA1302: InterfaceNamesMustBeginWithI

  It's actually a terribly silly rule, but unfortunately it's always been the convention in .NET code that all interfaces should begin with an I. This is the official recommendation from Microsoft. The naming guidelines tells us to "DO prefix interface names with the letter I, to indicate that the type is an interface.". At the same time, we are told that we should avoid Hungarian notation. It makes no sense. The recommendation probably stems from the misunderstanding that interfaces and classes always go in pairs: one implementing class per interface. Then there's an assumed conflict between the interface and the class as to which one gets the "real" name and which one gets a derivation. According to such a warped view, the choice is between IFoo (interface) and Foo (class) and Foo (interface) and CFoo or FooImpl (class). A much better solution is to solve this contention by having the class name reflect some concrete aspect of the implementation. An example would be to have a List interface with classes LinkedList and ArrayList. But alas, this battle is lost and there is no point in fighting wind-mills.

• SA1304: NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter

  Uncertain. I suppose the rationale is that non-private fields should have the same syntactic form as properties.

• SA1307: AccessibleFieldsMustBeginWithUpperCaseLetter

  Ref SA1304.

Insane

• SA1301: ElementMustBeginWithLowerCaseLetter

  The StyleCop documentation states that this rule is currently never triggered.

• SA1303: ConstFieldNamesMustBeginWithUpperCaseLetter

  I can't think of any good reasons for distinguishing syntactically between constants and non-constants - it feels like a watered-down form of Hungarian notation.

• SA1305: FieldNamesMustNotUseHungarianNotation

  In my experience this rule only ever leads to false positives: StyleCop will wrongly assume that some field name is written using Hungarian notation. Even though it is possible to whitelist words to prevent StyleCop from flagging false positives on a per-case basis, I think it's a waste of time to teach the analysis tool to avoid false positives when you never experience genuine violations of this rule.

• SA1306: FieldNamesMustBeginWithLowerCaseLetter

  I prefer the convention that field names begin with an underscore (ref SA1309). This makes it easy to distinguish between fields (which constitute object state) and variables (which are transient).

• SA1308: VariableNamesMustNotBePrefixed

  This is a silly rule preventing a convention I've never seen used in practice. There is no reason to apply rules that have no practical effect. (Of course, if you ever come across developers using this convention, enable this rule at once.)

• SA1309: FieldNamesMustNotBeginWithUnderscore

  I feel the exact opposite way: field names should begin with underscore.

• SA1310: FieldNamesMustNotContainUnderscore

  I suppose a violation of SA1309 is also a violation of SA1310? Otherwise this rule would be fine.

• SA1311: StaticReadonlyFieldsMustBeginWithUpperCaseLetter

  I can't think of any good reasons for distinguishing syntactically between static readonly fields and other fields. It feels like a watered-down form of Hungarian notation.

Ordering Rules (SA1200-)

In general, I don't think it makes sense to spend the developers' time sorting code elements according to arbitrary criteria like access modifiers or the alphabet. It creates unnecessary work without improving code navigation.

See http://www.stylecop.com/docs/Ordering%20Rules.html

Sane

• SA1203: ConstantsMustAppearBeforeFields

  Barely.

• SA1206: DeclarationKeywordsMustFollowOrder

  Barely.

• SA1207: ProtectedMustComeBeforeInternal

  This rule is so specific I suppose it practically never applies, but fine. It does no harm.

• SA1208: SystemUsingDirectivesMustBePlacedBeforeOtherUsingDirectives

  Under serious doubt.

• SA1209: UsingAliasDirectivesMustBePlacedAfterOtherUsingDirectives

  This makes things more readable.

• SA1212: PropertyAccessorsMustFollowOrder

  I've never seen this rule violated, but fine.

• SA1213: EventAccessorsMustFollowOrder

  This is fine too.

• SA1214: StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements

  Not sure it's terribly useful, but perhaps clean to distinguish between readonly and mutable.

• SA1215: InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements

  Not sure it's terribly useful, but perhaps clean to distinguish between readonly and mutable.

Insane

• SA1200: UsingDirectivesMustBePlacedWithinNamespace

  No!

• SA1201: ElementsMustAppearInTheCorrectOrder

  No. I am not spending my time memorizing the exact sequence of code elements required to please StyleCop.

• SA1202: ElementsMustBeOrderedByAccess

  No. This is actually harmful, it is much better to group code elements cohesively with respect to functionality (i.e. place private helper functions next to the public functions they help).

• SA1204: StaticElementsMustAppearBeforeInstanceElements

  No, I see no advantages gained by this rule that would offset the disadvantages: if I change from static to instance or the other way around I should have to manually move the code around? Insane.

• SA1205: PartialElementsMustDeclareAccess

  Ha ha! The rationale is that "StyleCop may not be able to determine the correct placement of the elements in the file". In other words, this insane rule is a prerequisite for other insane rules?

• SA1210: UsingDirectivesMustBeOrderedAlphabeticallyByNamespace

  This is quite common, but I find it pretty silly. Let ReSharper organize your using directives.

• SA1211: UsingAliasDirectivesMustBeOrderedAlphabeticallyByAliasName

  This is also pretty silly.

Readability Rules (SA1100-)

As always, StyleCop is mainly helpful when assisting in maintaining elementary code hygiene and consistency of formatting. As corrective-aggressive monkey (ref SA1122), StyleCop is annoying and outright damaging.

See http://www.stylecop.com/docs/Readability%20Rules.html

Sane

• SA1100: DoNotPrefixCallsWithBaseUnlessLocalImplementationExists

  I don't know if this is a problem warranting a rule but OK.

• SA1102: QueryClauseMustFollowPreviousClause

  Seems reasonable.

• SA1103: QueryClausesMustBeOnSeparateLinesOrAllOnOneLine

  This rule is fine.

• SA1104: QueryClauseMustBeginOnNewLineWhenPreviousClauseSpansMultipleLines

  This rule is fine.

• SA1105: QueryClausesSpanningMultipleLinesMustBeginOnOwnLine

  This rule is fine.

• SA1106: CodeMustNotContainEmptyStatements

  Hygiene.

• SA1107: CodeMustNotContainMultipleStatementsOnOneLine

  I think enforcing this rule is always a good idea, even inside lambda expressions.

• SA1108: BlockStatementsMustNotContainEmbeddedComments

  I have never seen anyone violate this rule, but it's a horrible practice.

• SA1109: BlockStatementsMustNotContainEmbeddedRegions

  I have never seen anyone violate this rule, but it's a horrible practice.

• SA1110: OpeningParenthesisMustBeOnDeclarationLine

  This rule is fine.

• SA1111: ClosingParenthesisMustBeOnLineOfOpeningParenthesis

  This rule is fine.

• SA1112: ClosingParenthesisMustBeOnLineOfOpeningParenthesis

  No controversy here.

• SA1113: CommaMustBeOnSameLineAsPreviousParameter

  Hygiene.

• SA1114: ParameterListMustFollowDeclaration

  Hygiene.

• SA1115: ParameterMustFollowComma

  I think this rule is fine.

• SA1116: SplitParametersMustStartOnLineAfterDeclaration

  I think this rule is fine.

• SA1117: ParametersMustBeOnSameLineOrSeparateLines

  I think this rule is fine.

• SA1118: ParameterMustNotSpanMultipleLines

  I think this rule is fine.

• SA1120: CommentsMustContainText

  This rule is fine.

• SA1123: DoNotPlaceRegionsWithinElements

  I'm not a fan of regions anywhere (ref SA1124), but this is a particularly bad way of using them.

• SA1125: UseShorthandForNullableTypes

  I can't think of any code samples where it makes sense to write Nullable<Foo> instead of Foo?.

Insane

• SA1101: PrefixLocalCallsWithThis

  No chance.

• SA1121: UseBuiltInTypeAlias

  I'm inclined to think that it is better to use the real type names when referring to static methods defined by those types, e.g. String.Compare("foo", "bar") is better than string.Compare("foo", "bar").

• SA1122: UseStringEmptyForEmptyStrings

  There is an established best practice in the .NET world that you are supposed to use string.Empty rather than "", but I think it's ridiculous. IMHO "" is preferable, since it is both more concise and more readable. There is also some superstition out there that string.Empty is supposed to be more performant than "", but that's pure hogwash. Since .NET 2.0, there has been no difference in performance between the two alternatives (and besides: talk about micro optimization!). Developers who let this myth dictate how they write code today should google "the monkey and the ladder". For a more thorough discussion, see http://stackoverflow.com/a/263257.

• SA1124: DoNotUseRegions

  I don't like regions (refactor if things get big and unwieldy!), but there might be cases where regions are OK and the overall principle is to err on the lenient side when in doubt.

• SA1126: PrefixCallsCorrectly

  WTF? No.

Spacing Rules (SA1000-)

This is primarily about simple code hygiene. This is what StyleCop does best.

See http://www.stylecop.com/docs/Spacing%20Rules.html

Sane

• SA1000: KeywordsMustBeSpacedCorrectly

  OK. Violations of this rule is just sloppy typing.

• SA1001: CommasMustBeSpacedCorrectly

  OK. Violations of this rule is just sloppy typing.

• SA1002: SemicolonsMustBeSpacedCorrectly

  OK. Violations of this rule is just sloppy typing.

• SA1003: SymbolsMustBeSpacedCorrectly

  Can't think of any code samples where it is acceptable to violate this rule.

• SA1004: DocumentationLinesMustBeginWithSingleSpace

  A bit of pedant rule, but probably makes the code a little tidier without causing problems.

• SA1005: SingleLineCommentsMustBeginWithSingleSpace

  Even more of a pedant rule, but the practice of adding the one spacing can probably be interned by muscle memory, and I suppose it makes things a little tidier.

• SA1006: PreprocessorKeywordsMustNotBePrecededBySpace

  This is the convention. I rarely see preprocessor keywords in the wild, so the rule rarely applies.

• SA1007: OperatorKeywordMustBeFollowedBySpace

  This is neat and clean.

• SA1008: OpeningParenthesisMustBeSpacedCorrectly

  With some doubts. I'm not sure if there might be code samples where it would be preferable to deviate from this rule.

• SA1009: ClosingParenthesisMustBeSpacedCorrectly

  Ref SA1008.

• SA1010: OpeningSquareBracketsMustBeSpacedCorrectly

  Ref SA1008.

• SA1011: ClosingSquareBracketsMustBeSpacedCorrectly

  Ref SA1008.

• SA1012: OpeningCurlyBracketsMustBeSpacedCorrectly

  Ref SA1008.

• SA1013: ClosingCurlyBracketsMustBeSpacedCorrectly

  Ref SA1008.

• SA1014: OpeningGenericBracketsMustBeSpacedCorrectly

  I think adhering to this rule is problem-free.

• SA1015: ClosingGenericBracketsMustBeSpacedCorrectly

  Ref SA1014.

• SA1016: OpeningAttributeBracketsMustBeSpacedCorrectly

  I think adhering to this rule is problem-free.

• SA1017: ClosingAttributeBracketsMustBeSpacedCorrectly

  Ref SA1016.

• SA1018: NullableTypeSymbolsMustNotBePrecededBySpace

  This is the convention.

• SA1019: MemberAccessSymbolsMustBeSpacedCorrectly

  No controversy here.

• SA1020: IncrementDecrementSymbolsMustBeSpacedCorrectly

  This is the convention.

• SA1021: NegativeSignsMustBeSpacedCorrectly

  I see no controversy here.

• SA1022: PositiveSignsMustBeSpacedCorrectly

  I see no controversy here.

• SA1023: DereferenceAndAccessOfSymbolsMustBeSpacedCorrectly

  I suppose this is the convention. Few practical implications, since the rule rarely applies.

• SA1024: ColonsMustBeSpacedCorrectly

  This is the convention.

• SA1025: CodeMustNotContainMultipleWhitespaceInARow

  No controversy here. Violations are due to sloppy typing.

• SA1027: TabsMustNotBeUsed

  No controversy here.

Insane

• SA1026: CodeMustNotContainSpaceAfterNewKeywordInImplicitlyTypedArrayAllocation

  Calling this rule "insane" is a bit harsh, but I don't think I concur. I prefer a whitespace.