What rules do Microsoft have turned on internally?
I've recently received a few requests asking about the Code Analysis rules we run internally against Microsoft's own code. While it might come as a surprise, we do not actually run every single rule against our own binaries. There are many reasons for this:
- Applicability. Not every rule is applicable to every project, for example, the Design rules might be turned off if you are writing a Windows Application
- Noise rate. Some rules have a low signal-to-noise ratio. While we try remove as much noise as possible from a rule, some rules, due to limitations in our analysis engine, still remain to be too noisy to be run regularly over large code bases. For example, some of the performance rules lack real context to make a good judge of whether a particular issue will really affect the performance of an application.
- Time. We have to ship eventually - attempting to fix every single violation, for every single binary is just not feasible nor advisable. Therefore we make calls to turn off some rules that may lack value and do not impact the security of the product.
Please note that the following rule sets are applicable only to the Developer Division (although Windows does actually follow the same bar), other divisions, such as MSN, Office, etc each have their own set of enabled rules that may or may not be match what is shown below.
There are two rule sets; the first, Public Rule Set, is for assemblies that design for public consumption. That is, assemblies that are designed to have user take a reference to them in their own projects (such as System.Core.dll). The second, Non-Public Rule Set, is for assemblies are not designed to be consumed by users (such as FxCopCmd.exe). Both sets are listed below:
Public Rule Set:
| Design | |
| CA1008 | EnumsShouldHaveZeroValue |
| CA1009 | DeclareEventHandlersCorrectly |
| CA1011 | ConsiderPassingBaseTypesAsParameters |
| CA1012 | AbstractTypesShouldNotHaveConstructors |
| CA1014 | MarkAssembliesWithClsCompliant |
| CA1017 | MarkAssembliesWithComVisible |
| CA1018 | MarkAttributesWithAttributeUsage |
| CA1019 | DefineAccessorsForAttributeArguments |
| CA1023 | IndexersShouldNotBeMultidimensional |
| CA1025 | ReplaceRepetitiveArgumentsWithParamsArray |
| CA1026 | DefaultParametersShouldNotBeUsed |
| CA1027 | MarkEnumsWithFlags |
| CA1028 | EnumStorageShouldBeInt32 |
| CA1030 | UseEventsWhereAppropriate |
| CA1032 | ImplementStandardExceptionConstructors |
| CA1034 | NestedTypesShouldNotBeVisible |
| CA1036 | OverrideMethodsOnComparableTypes |
| CA1038 | EnumeratorsShouldBeStronglyTyped |
| CA1039 | ListsAreStronglyTyped |
| CA1040 | AvoidEmptyInterfaces |
| CA1041 | ProvideObsoleteAttributeMessage |
| CA1043 | UseIntegralOrStringArgumentForIndexers |
| CA1044 | PropertiesShouldNotBeWriteOnly |
| CA1045 | DoNotPassTypesByReference |
| CA1046 | DoNotOverloadOperatorEqualsOnReferenceTypes |
| CA1050 | DeclareTypesInNamespaces |
| CA1051 | DoNotDeclareVisibleInstanceFields |
| CA1052 | StaticHolderTypesShouldBeSealed |
| CA1053 | StaticHolderTypesShouldNotHaveConstructors |
| CA1054 | UriParametersShouldNotBeStrings |
| CA1055 | UriReturnValuesShouldNotBeStrings |
| CA1056 | UriPropertiesShouldNotBeStrings |
| CA1057 | StringUriOverloadsCallSystemUriOverloads |
| CA1058 | TypesShouldNotExtendCertainBaseTypes |
| CA1059 | MembersShouldNotExposeCertainConcreteTypes |
| Globalization | |
| CA1300 | SpecifyMessageBoxOptions |
| CA1301 | AvoidDuplicateAccelerators |
| CA1304 | SpecifyCultureInfo |
| CA1305 | SpecifyIFormatProvider |
| CA1306 | SetLocaleForDataTypes |
| CA1307 | SpecifyStringComparison |
| CA1309 | UseOrdinalStringComparison |
| CA2101 | SpecifyMarshalingForPInvokeStringArguments |
| Interoperability | |
| CA1401 | PInvokesShouldNotBeVisible |
| CA1402 | AvoidOverloadsInComVisibleInterfaces |
| CA1403 | AutoLayoutTypesShouldNotBeComVisible |
| CA1404 | CallGetLastErrorImmediatelyAfterPInvoke |
| CA1405 | ComVisibleTypeBaseTypesShouldBeComVisible |
| CA1406 | AvoidInt64ArgumentsForVB6Clients |
| CA1408 | DoNotUseAutoDualClassInterfaceType |
| CA1413 | AvoidNonpublicFieldsInComVisibleValueTypes |
| Naming | |
| CA1700 | DoNotNameEnumValuesReserved |
| CA1701 | ResourceStringCompoundWordsShouldBeCasedCorrectly |
| CA1702 | CompoundWordsShouldBeCasedCorrectly |
| CA1703 | ResourceStringsShouldBeSpelledCorrectly |
| CA1704 | IdentifiersShouldBeSpelledCorrectly |
| CA1707 | IdentifiersShouldNotContainUnderscores |
| CA1708 | IdentifiersShouldDifferByMoreThanCase |
| CA1709 | IdentifiersShouldBeCasedCorrectly |
| CA1710 | IdentifiersShouldHaveCorrectSuffix |
| CA1711 | IdentifiersShouldNotHaveIncorrectSuffix |
| CA1712 | DoNotPrefixEnumValuesWithTypeName |
| CA1713 | EventsShouldNotHaveBeforeOrAfterPrefix |
| CA1714 | FlagsEnumsShouldHavePluralNames |
| CA1715 | IdentifiersShouldHaveCorrectPrefix |
| CA1716 | IdentifiersShouldNotMatchKeywords |
| CA1719 | ParameterNamesShouldNotMatchMemberNames |
| CA1720 | IdentifiersShouldNotContainTypeNames |
| CA1721 | PropertyNamesShouldNotMatchGetMethods |
| CA1722 | IdentifiersShouldNotHaveIncorrectPrefix |
| CA1724 | TypeNamesShouldNotMatchNamespaces |
| Performance | |
| CA1811 | AvoidUncalledPrivateCode |
| CA1812 | AvoidUninstantiatedInternalClasses |
| CA1813 | AvoidUnsealedAttributes |
| CA1815 | OverrideEqualsAndOperatorEqualsOnValueTypes |
| CA1816 | DisposeMethodsShouldCallSuppressFinalize |
| CA1819 | PropertiesShouldNotReturnArrays |
| Portability | |
| CA1900 | ValueTypeFieldsShouldBePortable |
| CA1901 | PInvokeDeclarationsShouldBePortable |
| Reliability | |
| CA2001 | AvoidCallingProblematicMethods |
| CA2002 | DoNotLockOnObjectsWithWeakIdentity |
| CA2004 | RemoveCallsToGCKeepAlive |
| CA2006 | UseSafeHandleToEncapsulateNativeResources |
| Security | |
| CA2102 | CatchNonClsCompliantExceptionsInGeneralHandlers |
| CA2103 | ReviewImperativeSecurity |
| CA2104 | DoNotDeclareReadOnlyMutableReferenceTypes |
| CA2105 | ArrayFieldsShouldNotBeReadOnly |
| CA2106 | SecureAsserts |
| CA2107 | ReviewDenyAndPermitOnlyUsage |
| CA2108 | ReviewDeclarativeSecurityOnValueTypes |
| CA2109 | ReviewVisibleEventHandlers |
| CA2111 | PointersShouldNotBeVisible |
| CA2112 | SecuredTypesShouldNotExposeFields |
| CA2114 | MethodSecurityShouldBeASupersetOfType |
| CA2115 | CallGCKeepAliveWhenUsingNativeResources |
| CA2116 | AptcaMethodsShouldOnlyCallAptcaMethods |
| CA2117 | AptcaTypesShouldOnlyExtendAptcaBaseTypes |
| CA2118 | ReviewSuppressUnmanagedCodeSecurityUsage |
| CA2119 | SealMethodsThatSatisfyPrivateInterfaces |
| CA2120 | SecureSerializationConstructors |
| CA2121 | StaticConstructorsShouldBePrivate |
| CA2122 | DoNotIndirectlyExposeMethodsWithLinkDemands |
| CA2123 | OverrideLinkDemandsShouldBeIdenticalToBase |
| CA2124 | WrapVulnerableFinallyClausesInOuterTry |
| CA2126 | TypeLinkDemandsRequireInheritanceDemands |
| CA2127 | SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode |
| CA2128 | SecurityTransparentCodeShouldNotAssert |
| CA2129 | SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode |
| Usage | |
| CA1806 | DoNotIgnoreMethodResults |
| CA2207 | InitializeValueTypeStaticFieldsInline |
| CA2208 | InstantiateArgumentExceptionsCorrectly |
| CA2209 | AssembliesShouldDeclareMinimumSecurity |
| CA2211 | NonConstantFieldsShouldNotBeVisible |
| CA2213 | DisposableFieldsShouldBeDisposed |
| CA2214 | DoNotCallOverridableMethodsInConstructors |
| CA2216 | DisposableTypesShouldDeclareFinalizer |
| CA2217 | DoNotMarkEnumsWithFlags |
| CA2218 | OverrideGetHashCodeOnOverridingEquals |
| CA2220 | FinalizersShouldCallBaseClassFinalizer |
| CA2221 | FinalizersShouldBeProtected |
| CA2224 | OverrideEqualsOnOverloadingOperatorEquals |
| CA2225 | OperatorOverloadsHaveNamedAlternates |
| CA2227 | CollectionPropertiesShouldBeReadOnly |
| CA2228 | DoNotShipUnreleasedResourceFormats |
| CA2229 | ImplementSerializationConstructors |
| CA2230 | UseParamsForVariableArguments |
| CA2233 | OperationsShouldNotOverflow |
| CA2234 | PassSystemUriObjectsInsteadOfStrings |
| CA2235 | MarkAllNonSerializableFields |
| CA2236 | CallBaseClassMethodsOnISerializableTypes |
| CA2237 | MarkISerializableTypesWithSerializable |
| CA2240 | ImplementISerializableCorrectly |
Non-Public Rule Set:
| Globalization | |
| CA2101 | SpecifyMarshalingForPInvokeStringArguments |
| Portability | |
| CA1900 | ValueTypeFieldsShouldBePortable |
| CA1901 | PInvokeDeclarationsShouldBePortable |
| Reliability | |
| CA2002 | DoNotLockOnObjectsWithWeakIdentity |
| Security | |
| CA2100 | ReviewSqlQueriesForSecurityVulnerabilities |
| CA2102 | CatchNonClsCompliantExceptionsInGeneralHandlers |
| CA2103 | ReviewImperativeSecurity |
| CA2104 | DoNotDeclareReadOnlyMutableReferenceTypes |
| CA2105 | ArrayFieldsShouldNotBeReadOnly |
| CA2106 | SecureAsserts |
| CA2107 | ReviewDenyAndPermitOnlyUsage |
| CA2108 | ReviewDeclarativeSecurityOnValueTypes |
| CA2109 | ReviewVisibleEventHandlers |
| CA2111 | PointersShouldNotBeVisible |
| CA2112 | SecuredTypesShouldNotExposeFields |
| CA2114 | MethodSecurityShouldBeASupersetOfType |
| CA2115 | CallGCKeepAliveWhenUsingNativeResources |
| CA2116 | AptcaMethodsShouldOnlyCallAptcaMethods |
| CA2117 | AptcaTypesShouldOnlyExtendAptcaBaseTypes |
| CA2118 | ReviewSuppressUnmanagedCodeSecurityUsage |
| CA2119 | SealMethodsThatSatisfyPrivateInterfaces |
| CA2120 | SecureSerializationConstructors |
| CA2121 | StaticConstructorsShouldBePrivate |
| CA2122 | DoNotIndirectlyExposeMethodsWithLinkDemands |
| CA2123 | OverrideLinkDemandsShouldBeIdenticalToBase |
| CA2124 | WrapVulnerableFinallyClausesInOuterTry |
| CA2126 | TypeLinkDemandsRequireInheritanceDemands |
| CA2127 | SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode |
| CA2128 | SecurityTransparentCodeShouldNotAssert |
| CA2129 | SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode |
| Usage | |
| CA2233 | OperationsShouldNotOverflow |
Now, while the above rules are set and mandated at the Division-level, individual teams can (and do) add additional rules. For example, most assemblies, whether public or not, at a minimum follow the Public Rule Set. The Code Analysis team itself actually turns on every single rule to run over the binaries that we release.
Also note that because they are set at the start of a product cycle and are not changed again until the start of the next cycle, rule sets do not include rules that are new to Visual Studio 2008 (with exception to security rules). This is prevent the situation of the introduction of a new rule causing existing code to be no longer be Code Analysis clean (ie moving the basket).
These rule sets will be revisited for Rosario and beyond.
Comments
Anonymous
August 09, 2007
Time for another weekly roundup of news that focuses on .NET and general development related contentAnonymous
August 10, 2007
Well, it turns out that Microsoft (Developer Division) itself isn't using all the code analysis (FxCop)Anonymous
August 14, 2007
The Visual Studio Code Analysis Team Blog on What rules do Microsoft have turned on internally? Bret...Anonymous
August 16, 2007
Here are some static code analysis features I have found useful. I'm interviewing with Microsoft on August 20, 2007, in Redmond, if anyone would like to discuss code analysis, etc. Thanks JeffBoyd@yahoo.ca AssertValid checking to add. Code is generated to create AssertValid functions and test each pointer data member. Boolean members to add to class 'Bool'. This lets meaningful names be used as parameters, instead of 'true' and 'false'. Class members not in a section. Class members without a name. Code to move to a section. Files to rename to match the class name. Files with the same name, in different directories. Function-body code-blocks to add. Function-parameters with unknown words. Functions with an undocumented return value. Functions with multiple return statements. Functions without definitions. Globals to move to a class. Large '.obj' files. Local variables with unknown words. Multiple variables declared in the same statement. Names that appear in both the 'known' and 'misspelled' word lists. New and misspelled words found in comments and identifiers. Sections that are nested. Sections to merge. Sections to move, to be alphabetically sorted. System-class function-calls to update to library-class function-calls. Tokens to update to macros. Undocumented classes. Undocumented data. Undocumented functions. And more. The Reports check: Class hierarchy organization. Constructor error checking. Constructor initializer lists. Destructor error checking. That related code is in the same section. The Reports help: Create a classes organizational tree, which is displayed by the browser. Sort lint messages and remove duplicate messages, to make linting faster. Rename class-member data names to start with 'm_'. Rename class-member names to contain known words. Rename class-member names to end with their type. Rename classes. Rename function local variables. Rename function return-values to start with 'result_'. Rename function-parameters. Rename functions. The Reports: AssertValid checking.messages AssertValid.messages autoexp char.messages Check_constructor_error_checking.messages Check_constructor_initializer_lists.messages Check_that_related_code_is_in_the_same_section.messages Class Bool.messages Class hierarchy.messages Class members not in a section.messages Class members without a name.messages Class-member names used in more than one section.messages Classes organizational tree.messages Code to move to a section.messages File to rename to match the class name.messages Files with the same name.messages Function-body code-blocks to add.messages Function-parameters with unknown words.messages Functions with an undocumented return value.messages Functions with multiple return statements.messages Functions without definitions.messages Globals.messages Large obj files.messages Lint Local variables with unknown words.messages Move_code.messages Multiple variables declared in the same statement.messages Names that appear in both the 'known' and 'misspelled' word lists new and misspelled words found in comments.messages new and misspelled words found in library module # comments.messages new and misspelled words.messages Rename class-member data names to start with 'm_' - These names are used more than once.messages Rename class-member data names to start with 'm_'.messages.messages Rename class-member names - These names are used more than once.messages Rename class-member names to end with their type - These names are used more than once.messages Rename class-member names to end with their type.messages Rename class-member names.messages Rename function local variables.unsorted.messages Rename function return-value to start with 'result_'.messages Rename function-parameters.sorted.messages Rename Function-parameters.unsorted.messages Sections that are nested.messages Sections to merge.messages Sections to move, to be alphabetically sorted.messages spell_checking_Enabled System #include statements that do not use angle brackets.messages System objects to update to library objects.messages system-class function-calls.messages tokens_to_update_to_macros.messages Undocumented classes.messages Undocumented data.messages Undocumented functions.messages usertypeAnonymous
August 16, 2007
My correct email address is Jeffers_Boyd@yahoo.caAnonymous
August 19, 2007
Hi David. Has CA1040 been removed from the public set for VS2008 or LINQ? There are some empty interfaces in LINQ.Anonymous
August 20, 2007
Peter: No CA1040 (AvoidEmptyInterfaces) has not been removed from the public set, however, it appears that we have a bug in the rule that prevents it from firing on some of the interfaces in System.Core.dll. We have logic that does not fire (correctly) if you combine two or more interfaces, however, it should (but currently doesn't) fire when combining two interfaces and one of them is already in your hierarchy. I've filed a bug on this, however, it will be likely fixed post Visual Studio 2008.Anonymous
August 24, 2007
Hmm, interesting. I guess that means the empty interfaces in LINQ will remain...Anonymous
September 21, 2007
CA2217 DoNotMarkEnumsWithFlags CA1027 MarkEnumsWithFlags These seem to conflict. How can you run with both?Anonymous
September 21, 2007
Mike, They seem in conflict but they are not. One checks for enums that are marked with [Flags] but shouldn't be and the other checks for enums that aren't marked with [Flags] but should be. Confusing - hopefully in the future we can merge them to reduce the confusion. Regards DavidAnonymous
October 09, 2007
Hi, I am using TFS2008 and VS2008 (beta2). The point is that I cannot find the CA 1062 rule (check paramters against null)... Where is it ? Where is the CA 1818 (stringbuilder usage) ? Thanx in advance, MessaoudAnonymous
October 10, 2007
Messaoud: Unfortunately, these rules were based on our old data flow engine and were removed when it was removed from the product. We will be recovering them in a future version of Visual Studio.Anonymous
October 11, 2007
Ever wondered if Microsoft use FxCop themselves, and which rules they have turned on? Well, the VisualAnonymous
October 14, 2007
David M. Kean , has posted a list of Code Analysis rules which runs internally against Microsoft's ownAnonymous
October 14, 2007
One of the things I have found most irritating about FxCop are the default rules which are not meaningful to most programs, such as CA2210 - Assemblies should have strong names The vast majority of developers out here in the real world don't understand these things. They see it come up as a warning, and think it's important to fix. It would be nice if Microsoft configured fxcop by default with a intelligent set of rules. Basically like this list. Then if groups wanted to enable things above and beyond that, they could. But it would save a lot of headaches and arguments. Thanks for this listAnonymous
October 14, 2007
Thanks for posting This stuff. Surely will be helpfulAnonymous
October 15, 2007
The Visual Studio Code Analysis Team Blog : What rules do Microsoft have turned on internally? (tagsAnonymous
October 26, 2007
http://blogs.msdn.com/fxcop/archive/2007/08/09/what-rules-do-microsoft-have-turned-on-internally.aspx nullAnonymous
November 22, 2007
In previous posts about Code Metrics and Code Reviews , I explored some metrics and techniques that IAnonymous
November 23, 2008
Rules to Enable When Using Code AnalysisAnonymous
February 05, 2009
[ Nacsa Sándor , 2009. január 19. – február 5.] Ez a Team System változat fejlett eszközrendszert kínálAnonymous
March 12, 2009
Recently I had the chance to examine, in detail, each of the code analysis rules built into Visual Studio