MiKo-Analyzers
Provides analyzers that are based on the .NET Compiler Platform (Roslyn) and can be used inside Visual Studio 2019 (v16.11) or 2022 (v17.6).
How to install an Roslyn analyzer is described here.
Screenshots on how to use such analyzers can be found here.
Build / Project status
Available Rules
The following tables list all the 435 rules that are currently provided by the analyzer.
Metrics
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_0001 | Method is too big | ✓ | - |
| MiKo_0002 | Method is too complex | ✓ | - |
| MiKo_0003 | Type is too big | ✓ | - |
| MiKo_0004 | Method has too many parameters | ✓ | - |
| MiKo_0005 | Local function is too big | ✓ | - |
| MiKo_0006 | Local function is too complex | ✓ | - |
| MiKo_0007 | Local function has too many parameters | ✓ | - |
Naming
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_1000 | 'System.EventArgs' types should be suffixed with 'EventArgs' | ✓ | ✓ |
| MiKo_1001 | 'System.EventArgs' parameters should be named 'e' | ✓ | ✓ |
| MiKo_1002 | Parameters should be named according the .NET Framework Design Guidelines for event handlers | ✓ | ✓ |
| MiKo_1003 | Event handling method names should follow the .NET Framework Design Guidelines | ✓ | ✓ |
| MiKo_1004 | Events should not contain term 'Event' in their names | ✓ | ✓ |
| MiKo_1005 | 'System.EventArgs' variables should be named properly | ✓ | ✓ |
| MiKo_1006 | Events should use 'EventHandler<T>' with 'EventArgs' which are named after the event | ✓ | - |
| MiKo_1007 | Events and their corresponding 'EventArgs' types should be located in the same namespace | ✓ | - |
| MiKo_1008 | Parameters should be named according the .NET Framework Design Guidelines for DependencyProperty event handlers | ✓ | ✓ |
| MiKo_1009 | 'System.EventHandler' variables should be named properly | ✓ | ✓ |
| MiKo_1010 | Methods should not contain 'CanExecute' or 'Execute' in their names | ✓ | ✓ |
| MiKo_1011 | Methods should not contain 'Do' in their names | ✓ | ✓ |
| MiKo_1012 | Methods should be named 'Raise' instead of 'Fire' | ✓ | ✓ |
| MiKo_1013 | Methods should not be named 'Notify' or 'OnNotify' | ✓ | ✓ |
| MiKo_1014 | Methods should not be named with ambiguous 'Check' | ✓ | ✓ |
| MiKo_1015 | Methods should be named 'Initialize' instead of 'Init' | ✓ | ✓ |
| MiKo_1016 | Factory methods should be named 'Create' | ✓ | ✓ |
| MiKo_1017 | Methods should not be prefixed with 'Get' or 'Set' if followed by 'Is', 'Can' or 'Has' | ✓ | ✓ |
| MiKo_1018 | Methods should not be suffixed with noun of a verb | ✓ | ✓ |
| MiKo_1019 | 'Clear' and 'Remove' methods should be named based on their number of parameters | ✓ | ✓ |
| MiKo_1020 | Type names should be limited in length | - | - |
| MiKo_1021 | Method names should be limited in length | - | - |
| MiKo_1022 | Parameter names should be limited in length | - | - |
| MiKo_1023 | Field names should be limited in length | - | - |
| MiKo_1024 | Property names should be limited in length | - | - |
| MiKo_1025 | Event names should be limited in length | - | - |
| MiKo_1026 | Variable names should be limited in length | - | - |
| MiKo_1027 | Variable names in loops should be limited in length | - | - |
| MiKo_1028 | Local function names should be limited in length | - | - |
| MiKo_1030 | Types should not have an 'Abstract' or 'Base' marker to indicate that they are base types | ✓ | ✓ |
| MiKo_1031 | Entity types should not use a 'Model' suffix | ✓ | ✓ |
| MiKo_1032 | Methods dealing with entities should not use a 'Model' as marker | ✓ | ✓ |
| MiKo_1033 | Parameters representing entities should not use a 'Model' suffix | ✓ | ✓ |
| MiKo_1034 | Fields representing entities should not use a 'Model' suffix | ✓ | ✓ |
| MiKo_1035 | Properties dealing with entities should not use a 'Model' marker | ✓ | ✓ |
| MiKo_1036 | Events dealing with entities should not use a 'Model' marker | ✓ | ✓ |
| MiKo_1037 | Types should not be suffixed with 'Enum' | ✓ | ✓ |
| MiKo_1038 | Classes that contain extension methods should end with same suffix | ✓ | ✓ |
| MiKo_1039 | The 'this' parameter of extension methods should have a default name | ✓ | ✓ |
| MiKo_1040 | Parameters should not be suffixed with implementation details | ✓ | - |
| MiKo_1041 | Fields should not be suffixed with implementation details | ✓ | - |
| MiKo_1042 | 'CancellationToken' parameters should have specific name | ✓ | ✓ |
| MiKo_1043 | 'CancellationToken' variables should have specific name | ✓ | ✓ |
| MiKo_1044 | Commands should be suffixed with 'Command' | ✓ | ✓ |
| MiKo_1045 | Methods that are invoked by commands should not be suffixed with 'Command' | ✓ | ✓ |
| MiKo_1046 | Asynchronous methods should follow the Task-based Asynchronous Pattern (TAP) | ✓ | ✓ |
| MiKo_1047 | Methods not following the Task-based Asynchronous Pattern (TAP) should not lie about being asynchronous | ✓ | ✓ |
| MiKo_1048 | To ease maintenance, the names of classes that are value converters should end with the same suffix | ✓ | ✓ |
| MiKo_1049 | Do not use requirement terms such as 'Shall', 'Should', 'Must' or 'Need' for names | ✓ | ✓ |
| MiKo_1050 | Return values should have descriptive names | ✓ | ✓ |
| MiKo_1051 | Do not suffix parameters with delegate types | ✓ | ✓ |
| MiKo_1052 | Do not suffix variables with delegate types | ✓ | ✓ |
| MiKo_1053 | Do not suffix fields with delegate types | ✓ | ✓ |
| MiKo_1054 | Do not name types 'Helper' or 'Utility' | ✓ | ✓ |
| MiKo_1055 | Dependency properties should be suffixed with 'Property' (as in the .NET Framework) | ✓ | ✓ |
| MiKo_1056 | Dependency properties should be prefixed with property names (as in the .NET Framework) | ✓ | ✓ |
| MiKo_1057 | Dependency property keys should be suffixed with 'Key' (as in the .NET Framework) | ✓ | ✓ |
| MiKo_1058 | Dependency property keys should be prefixed with property names (as in the .NET Framework) | ✓ | ✓ |
| MiKo_1059 | Do not name types 'Impl' or 'Implementation' | ✓ | ✓ |
| MiKo_1060 | Use '<Entity>NotFound' instead of 'Get<Entity>Failed' or '<Entity>Missing' | ✓ | - |
| MiKo_1061 | The name of 'Try' method's [out] parameter should be specific | ✓ | ✓ |
| MiKo_1062 | 'Can/Has/Contains' methods, properties or fields shall consist of only a few words | ✓ | - |
| MiKo_1063 | Do not use abbreviations in names | ✓ | - |
| MiKo_1064 | Parameter names reflect their meaning and not their type | ✓ | - |
| MiKo_1065 | Operator parameters should be named according the .NET Framework Design Guidelines for operator overloads | ✓ | ✓ |
| MiKo_1066 | Constructor parameters that are assigned to a property should be named after the property | ✓ | ✓ |
| MiKo_1067 | Methods should not contain 'Perform' in their names | ✓ | ✓ |
| MiKo_1068 | Workflow methods should be named 'CanRun' or 'Run' | ✓ | - |
| MiKo_1069 | Property names reflect their meaning and not their type | ✓ | - |
| MiKo_1070 | Local collection variables shall use plural name | ✓ | ✓ |
| MiKo_1071 | Local boolean variables should be named as statements and not as questions | ✓ | - |
| MiKo_1072 | Boolean properties or methods should be named as statements and not as questions | ✓ | - |
| MiKo_1073 | Boolean fields should be named as statements and not as questions | ✓ | - |
| MiKo_1074 | Objects used to lock on should be suffixed with 'Lock' | ✓ | - |
| MiKo_1075 | Non-'System.EventArgs' types should not be suffixed with 'EventArgs' | ✓ | ✓ |
| MiKo_1076 | Prism event types should be suffixed with 'Event' | ✓ | ✓ |
| MiKo_1080 | Names should contain numbers instead of their spellings | ✓ | - |
| MiKo_1081 | Methods should not be suffixed with a number | ✓ | ✓ |
| MiKo_1082 | Properties should not be suffixed with a number if their types have number suffixes | ✓ | ✓ |
| MiKo_1083 | Fields should not be suffixed with a number if their types have number suffixes | ✓ | ✓ |
| MiKo_1084 | Variables should not be suffixed with a number if their types have number suffixes | ✓ | ✓ |
| MiKo_1085 | Parameters should not be suffixed with a number | ✓ | ✓ |
| MiKo_1086 | Methods should not be named using numbers as slang | ✓ | - |
| MiKo_1087 | Name constructor parameters after their counterparts in the base class | ✓ | ✓ |
| MiKo_1088 | Singleton instances should be named 'Instance' | ✓ | - |
| MiKo_1090 | Parameters should not be suffixed with specific types | ✓ | ✓ |
| MiKo_1091 | Variables should not be suffixed with specific types | ✓ | ✓ |
| MiKo_1092 | 'Ability' Types should not be suffixed with redundant information | ✓ | ✓ |
| MiKo_1093 | Do not use the suffix 'Object' or 'Struct' | ✓ | ✓ |
| MiKo_1094 | Do not suffix types with passive namespace names | ✓ | - |
| MiKo_1095 | Do not use 'Delete' and 'Remove' both in names and documentation | ✓ | - |
| MiKo_1096 | Names should use 'Failed' instead of 'NotSuccessful' | ✓ | - |
| MiKo_1097 | Parameter names should not follow the naming scheme for fields | ✓ | ✓ |
| MiKo_1098 | Type names should reflect the business interface(s) they implement | ✓ | - |
| MiKo_1099 | Matching parameters on method overloads should have identical names | ✓ | ✓ |
| MiKo_1100 | Test classes should start with the name of the type under test | ✓ | - |
| MiKo_1101 | Test classes should end with 'Tests' | ✓ | ✓ |
| MiKo_1102 | Test methods should not contain 'Test' in their names | ✓ | ✓ |
| MiKo_1103 | Test initialization methods should be named 'PrepareTest' | ✓ | ✓ |
| MiKo_1104 | Test cleanup methods should be named 'CleanupTest' | ✓ | ✓ |
| MiKo_1105 | One-time test initialization methods should be named 'PrepareTestEnvironment' | ✓ | ✓ |
| MiKo_1106 | One-time test cleanup methods should be named 'CleanupTestEnvironment' | ✓ | ✓ |
| MiKo_1107 | Test methods should not be in Pascal-casing | ✓ | ✓ |
| MiKo_1108 | Do not name variables, parameters, fields and properties 'Mock', 'Stub', 'Fake' or 'Shim' | ✓ | ✓ |
| MiKo_1109 | Prefix testable types with 'Testable' instead of using the 'Ut' suffix | ✓ | ✓ |
| MiKo_1110 | Test methods with parameters should be suffixed with underscore | ✓ | ✓ |
| MiKo_1111 | Test methods without parameters should not be suffixed with underscore | ✓ | ✓ |
| MiKo_1112 | Do not name test data 'arbitrary' | ✓ | ✓ |
| MiKo_1113 | Test methods should not be named according BDD style | ✓ | - |
| MiKo_1114 | Test methods should not be named 'HappyPath' or 'BadPath' | ✓ | - |
| MiKo_1115 | Test methods should be named in a fluent way | ✓ | ✓ |
| MiKo_1200 | Name exceptions in catch blocks consistently | ✓ | ✓ |
| MiKo_1201 | Name exceptions as parameters consistently | ✓ | ✓ |
| MiKo_1300 | Unimportant identifiers in lambda statements should be named '_' | ✓ | ✓ |
| MiKo_1400 | Namespace names should be in plural | ✓ | - |
| MiKo_1401 | Namespaces should not contain technical language names | ✓ | - |
| MiKo_1402 | Namespaces should not be named after WPF specific design patterns | ✓ | - |
| MiKo_1403 | Namespaces should not be named after any of their parent namespaces | ✓ | - |
| MiKo_1404 | Namespaces should not contain unspecific names | ✓ | - |
| MiKo_1405 | Namespaces should not contain 'Lib' | ✓ | - |
| MiKo_1406 | Value converters should be placed in 'Converters' namespace | ✓ | - |
| MiKo_1407 | Test namespaces should not contain 'Test' | ✓ | - |
| MiKo_1408 | Extension methods should be placed in same namespace as the extended types | ✓ | - |
| MiKo_1409 | Do not prefix or suffix namespaces with underscores | ✓ | - |
Documentation
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_2000 | Documentation should be valid XML | ✓ | ✓ |
| MiKo_2001 | Events should be documented properly | ✓ | ✓ |
| MiKo_2002 | EventArgs should be documented properly | ✓ | ✓ |
| MiKo_2003 | Documentation of event handlers should have a default starting phrase | ✓ | ✓ |
| MiKo_2004 | Documentation of event handler parameter names should follow .NET Framework Design Guidelines for event handlers | ✓ | ✓ |
| MiKo_2005 | Textual references to EventArgs should be documented properly | ✓ | - |
| MiKo_2006 | Routed events should be documented as done by the .NET Framework | ✓ | ✓ |
| MiKo_2010 | Sealed classes should document being sealed | ✓ | ✓ |
| MiKo_2011 | Unsealed classes should not lie about sealing | ✓ | ✓ |
| MiKo_2012 | <summary> documentation should describe the type's responsibility | ✓ | ✓ |
| MiKo_2013 | <summary> documentation of Enums should have a default starting phrase | ✓ | ✓ |
| MiKo_2014 | Dispose methods should be documented as done by the .NET Framework | ✓ | ✓ |
| MiKo_2015 | Documentation should use 'raise' or 'throw' instead of 'fire' | ✓ | ✓ |
| MiKo_2016 | Documentation for asynchronous methods should start with specific phrase | ✓ | ✓ |
| MiKo_2017 | Dependency properties should be documented as done by the .NET Framework | ✓ | ✓ |
| MiKo_2018 | Documentation should not use the ambiguous terms 'Check' or 'Test' | ✓ | ✓ |
| MiKo_2019 | <summary> documentation should start with a third person singular verb (for example "Provides ") | ✓ | - |
| MiKo_2020 | Inherited documentation should be used with <inheritdoc /> marker | ✓ | ✓ |
| MiKo_2021 | Documentation of parameter should have a default starting phrase | ✓ | - |
| MiKo_2022 | Documentation of [out] parameters should have a default starting phrase | ✓ | ✓ |
| MiKo_2023 | Documentation of Boolean parameters should have a default starting phrase | ✓ | ✓ |
| MiKo_2024 | Documentation of Enum parameters should have a default starting phrase | ✓ | ✓ |
| MiKo_2025 | Documentation of 'CancellationToken' parameters should have a default starting phrase | ✓ | ✓ |
| MiKo_2026 | Used parameters should not be documented to be unused | ✓ | - |
| MiKo_2027 | Serialization constructor parameters shall be documented with a specific phrase | ✓ | ✓ |
| MiKo_2028 | Documentation of parameter should not just contain the name of the parameter | ✓ | - |
| MiKo_2029 | <inheritdoc> documentation should not use a 'cref' to itself | ✓ | ✓ |
| MiKo_2030 | Documentation of return value should have a default starting phrase | ✓ | - |
| MiKo_2031 | Documentation of Task return value should have a specific (starting) phrase | ✓ | ✓ |
| MiKo_2032 | Documentation of Boolean return value should have a specific phrase | ✓ | ✓ |
| MiKo_2033 | Documentation of String return value should have a default starting phrase | ✓ | ✓ |
| MiKo_2034 | Documentation of Enum return value should have a default starting phrase | ✓ | ✓ |
| MiKo_2035 | Documentation of collection return value should have a default starting phrase | ✓ | ✓ |
| MiKo_2036 | Documentation of Boolean or Enum property shall describe the default value | ✓ | ✓ |
| MiKo_2037 | <summary> documentation of command properties should have a default starting phrase | ✓ | ✓ |
| MiKo_2038 | <summary> documentation of command should have a default starting phrase | ✓ | ✓ |
| MiKo_2039 | <summary> documentation of classes that contain extension methods should have a default starting phrase | ✓ | ✓ |
| MiKo_2040 | <see langword="..."/> should be used instead of <c>...</c> | ✓ | ✓ |
| MiKo_2041 | <summary> documentation should not contain other documentation tags | ✓ | ✓ |
| MiKo_2042 | Documentation should use '<para/>' XML tags instead of '<br/>' HTML tags | ✓ | ✓ |
| MiKo_2043 | <summary> documentation of custom delegates should have a default starting phrase | ✓ | ✓ |
| MiKo_2044 | Documentation references method parameters correctly | ✓ | ✓ |
| MiKo_2045 | <summary> documentation should not reference parameters | ✓ | ✓ |
| MiKo_2046 | Documentation should reference type parameters correctly | ✓ | ✓ |
| MiKo_2047 | <summary> documentation of Attributes should have a default starting phrase | ✓ | - |
| MiKo_2048 | <summary> documentation of value converters should have a default starting phrase | ✓ | ✓ |
| MiKo_2049 | Documentation should be more explicit and not use 'will be' | ✓ | ✓ |
| MiKo_2050 | Exceptions should be documented following the .NET Framework | ✓ | ✓ |
| MiKo_2051 | Thrown Exceptions should be documented as kind of a condition (such as '<paramref name="xyz"/> is <c>42</c>') | ✓ | ✓ |
| MiKo_2052 | Throwing of ArgumentNullException should be documented using a default phrase | ✓ | ✓ |
| MiKo_2053 | Throwing of ArgumentNullException should be documented only for reference type parameters | ✓ | - |
| MiKo_2054 | Throwing of ArgumentException should be documented using a default starting phrase | ✓ | ✓ |
| MiKo_2055 | Throwing of ArgumentOutOfRangeException should be documented using a default starting phrase | ✓ | ✓ |
| MiKo_2056 | Throwing of ObjectDisposedException should be documented using a default ending phrase | ✓ | ✓ |
| MiKo_2057 | Types that are not disposable shall not throw an ObjectDisposedException | ✓ | ✓ |
| MiKo_2059 | Multiple documentation of same exception should be consolidated into one | ✓ | ✓ |
| MiKo_2060 | Factories should be documented in an uniform way | ✓ | ✓ |
| MiKo_2070 | <summary> documentation should not start with 'Returns' | ✓ | ✓ |
| MiKo_2071 | <summary> documentation for methods that return Enum types should not contain phrase for boolean type | ✓ | - |
| MiKo_2072 | <summary> documentation should not start with 'Try' | ✓ | ✓ |
| MiKo_2073 | <summary> documentation of 'Contains' methods should start with 'Determines whether ' | ✓ | ✓ |
| MiKo_2074 | Documentation of parameter of 'Contains' method should have a default ending phrase | ✓ | ✓ |
| MiKo_2075 | Documentation should use the term 'callback' instead of 'action', 'func' or 'function' | ✓ | ✓ |
| MiKo_2076 | Documentation should document default values of optional parameters | ✓ | ✓ |
| MiKo_2077 | <summary> documentation should not contain <code> | ✓ | - |
| MiKo_2078 | <code> documentation should not contain XML tags | ✓ | - |
| MiKo_2080 | <summary> documentation of fields should have a default starting phrase | ✓ | ✓ |
| MiKo_2081 | <summary> documentation of public-visible read-only fields should have a default ending phrase | ✓ | ✓ |
| MiKo_2082 | <summary> documentation of Enum members should not start with default starting phrases of Enum <summary> documentation | ✓ | ✓ |
| MiKo_2090 | Documentation for equality operator shall have default phrase | ✓ | ✓ |
| MiKo_2091 | Documentation for inequality operator shall have default phrase | ✓ | ✓ |
| MiKo_2100 | <example> documentation should start with descriptive default phrase | ✓ | ✓ |
| MiKo_2101 | <example> documentation should show code example in <code> tags | ✓ | ✓ |
| MiKo_2200 | Use a capitalized letter to start the comment | ✓ | ✓ |
| MiKo_2201 | Use a capitalized letter to start the sentences in the comment | ✓ | - |
| MiKo_2202 | Documentation should use the term 'identifier' instead of 'id' | ✓ | ✓ |
| MiKo_2203 | Documentation should use the term 'unique identifier' instead of 'guid' | ✓ | ✓ |
| MiKo_2204 | Documentation should use <list> for enumerations | ✓ | ✓ |
| MiKo_2205 | Documentation should use <note> for important information | ✓ | - |
| MiKo_2206 | Documentation should not use the term 'flag' | ✓ | - |
| MiKo_2207 | <summary> documentation shall be short | ✓ | - |
| MiKo_2208 | Documentation should not use the term 'an instance of' | ✓ | ✓ |
| MiKo_2209 | Do not use double periods in documentation | ✓ | ✓ |
| MiKo_2210 | Documentation should use the term 'information' instead of 'info' | ✓ | ✓ |
| MiKo_2211 | Enum members should not have <remarks> sections | ✓ | ✓ |
| MiKo_2212 | Documentation should use the phrase 'failed' instead of 'was not successful' | ✓ | ✓ |
| MiKo_2213 | Documentation should not use the contradiction "n't" | ✓ | ✓ |
| MiKo_2214 | Documentation should not contain empty lines | ✓ | ✓ |
| MiKo_2215 | Sentences in documentation shall be short | ✓ | - |
| MiKo_2216 | Use <paramref> instead of <param> to reference parameters | ✓ | ✓ |
| MiKo_2217 | <list> documentation is done properly | ✓ | ✓ |
| MiKo_2218 | Documentation should use shorter terms instead of longer term 'used to/in/by' | ✓ | ✓ |
| MiKo_2219 | Do not use question or explamation marks in documentation | ✓ | - |
| MiKo_2220 | Documentation should use 'to seek' instead of 'to look for', 'to inspect for' or 'to test for' | ✓ | ✓ |
| MiKo_2221 | Documentation should not use empty XML tags | ✓ | - |
| MiKo_2222 | Documentation should use the term 'identification' instead of 'ident' | ✓ | ✓ |
| MiKo_2223 | Documentation links references via <see cref="..."/> | ✓ | - |
| MiKo_2224 | Documentation should have XML tags and texts placed on separate lines | ✓ | ✓ |
| MiKo_2225 | Code marked with <c> tags should be placed on single line | ✓ | ✓ |
| MiKo_2226 | Documentation should explain the 'Why' and not the 'That' | ✓ | - |
| MiKo_2227 | Documentation should not contain ReSharper suppressions | ✓ | - |
| MiKo_2228 | Documentation should use positive wording instead of negative | ✓ | - |
| MiKo_2229 | Documentation should not contain left-over XML fragments | ✓ | ✓ |
| MiKo_2300 | Comments should explain the 'Why' and not the 'How' | ✓ | - |
| MiKo_2301 | Do not use obvious comments in AAA-Tests | ✓ | ✓ |
| MiKo_2302 | Do not keep code that is commented out | ✓ | - |
| MiKo_2303 | Do not end comments with a period | ✓ | ✓ |
| MiKo_2304 | Do not formulate comments as questions | ✓ | - |
| MiKo_2305 | Do not use double periods in comments | ✓ | ✓ |
| MiKo_2306 | End comments with a period | - | - |
| MiKo_2307 | Comments should use the phrase 'failed' instead of 'was not successful' | ✓ | ✓ |
| MiKo_2308 | Do not place comment on single line before closing brace but after code | ✓ | ✓ |
| MiKo_2309 | Comments should not use the contradiction "n't" | ✓ | ✓ |
| MiKo_2310 | Comments should explain the 'Why' and not the 'That' | ✓ | - |
Maintainability
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_3000 | Do not use empty regions | ✓ | - |
| MiKo_3001 | Custom delegates should not be used | ✓ | - |
| MiKo_3002 | Classes should not have too many dependencies | ✓ | - |
| MiKo_3003 | Events should follow .NET Framework Design Guidelines for events | ✓ | - |
| MiKo_3004 | Property setters of EventArgs shall be private | ✓ | - |
| MiKo_3005 | Methods named 'Try' should follow the Trier-Doer-Pattern | ✓ | - |
| MiKo_3006 | 'CancellationToken' parameter should be last method parameter | ✓ | - |
| MiKo_3007 | Do not use LINQ method and declarative query syntax in same method | ✓ | - |
| MiKo_3008 | Method should not return collections that can be changed from outside | ✓ | - |
| MiKo_3009 | Commands should invoke only named methods and no lambda expressions | ✓ | - |
| MiKo_3010 | Do not create or throw reserved exception types | ✓ | - |
| MiKo_3011 | Thrown ArgumentExceptions (or its subtypes) shall provide the correct parameter name | ✓ | ✓ |
| MiKo_3012 | Thrown ArgumentOutOfRangeExceptions (or its subtypes) shall provide the actual value that causes the exception to be thrown | ✓ | ✓ |
| MiKo_3013 | The 'default' clause in 'switch' statements should throw an ArgumentOutOfRangeException (or subtype), but no ArgumentException | ✓ | ✓ |
| MiKo_3014 | InvalidOperationException, NotImplementedException and NotSupportedException should have a reason as message | ✓ | ✓ |
| MiKo_3015 | Throw InvalidOperationExceptions (instead of ArgumentExceptions or its subtypes) to indicate inappropriate states of parameterless methods | ✓ | ✓ |
| MiKo_3016 | Do not throw ArgumentNullException for inappropriate states of property return values | ✓ | ✓ |
| MiKo_3017 | Do not swallow exceptions when throwing new exceptions | ✓ | ✓ |
| MiKo_3018 | Throw ObjectDisposedExceptions on publicly visible methods of disposable types | ✓ | - |
| MiKo_3020 | Use 'Task.CompletedTask' instead of 'Task.FromResult' | ✓ | ✓ |
| MiKo_3021 | Do not use 'Task.Run' in the implementation | ✓ | - |
| MiKo_3022 | Do not return Task<IEnumerable> or Task<IEnumerable<T>> | ✓ | - |
| MiKo_3023 | Do not use 'CancellationTokenSource' as parameter | ✓ | - |
| MiKo_3024 | Do not use the [ref] keyword on reference parameters | ✓ | - |
| MiKo_3025 | Do not re-assign method parameters | ✓ | - |
| MiKo_3026 | Unused parameters should be removed | ✓ | - |
| MiKo_3027 | Parameters should not be marked to be reserved for future usage | ✓ | - |
| MiKo_3028 | Do not assign null to lambda parameters | ✓ | - |
| MiKo_3029 | Event registrations should not cause memory leaks | ✓ | - |
| MiKo_3030 | Methods should follow the Law of Demeter | - | - |
| MiKo_3031 | ICloneable.Clone() should not be implemented | ✓ | - |
| MiKo_3032 | Use 'nameof' instead of Cinch for names of properties for created 'PropertyChangedEventArgs' instances | ✓ | ✓ |
| MiKo_3033 | Use 'nameof' for names of properties for created 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs' instances | ✓ | ✓ |
| MiKo_3034 | PropertyChanged event raiser shall use [CallerMemberName] attribute | ✓ | ✓ |
| MiKo_3035 | Do not invoke 'WaitOne' methods without timeouts | ✓ | - |
| MiKo_3036 | Prefer to use 'TimeSpan' factory methods instead of constructors | ✓ | ✓ |
| MiKo_3037 | Do not use magic numbers for timeouts | ✓ | - |
| MiKo_3038 | Do not use magic numbers | ✓ | - |
| MiKo_3039 | Properties should not use Linq or yield | ✓ | - |
| MiKo_3040 | Do not use Booleans unless you are absolutely sure that you will never ever need more than 2 values | ✓ | - |
| MiKo_3041 | EventArgs shall not use delegates | ✓ | - |
| MiKo_3042 | EventArgs shall not implement interfaces | ✓ | - |
| MiKo_3043 | Use 'nameof' for WeakEventManager event (de-)registrations | ✓ | ✓ |
| MiKo_3044 | Use 'nameof' to compare property names of 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs' | ✓ | ✓ |
| MiKo_3045 | Use 'nameof' for EventManager event registrations | ✓ | ✓ |
| MiKo_3046 | Use 'nameof' for property names of property raising methods | ✓ | ✓ |
| MiKo_3047 | Use 'nameof' for applied [ContentProperty] attributes | ✓ | ✓ |
| MiKo_3048 | ValueConverters shall have the [ValueConversion] attribute applied | ✓ | - |
| MiKo_3049 | Enum members shall have the [Description] attribute applied | ✓ | - |
| MiKo_3050 | DependencyProperty fields should be 'public static readonly' | ✓ | ✓ |
| MiKo_3051 | DependencyProperty fields should be properly registered | ✓ | ✓ |
| MiKo_3052 | DependencyPropertyKey fields should be non-public 'static readonly' | ✓ | ✓ |
| MiKo_3053 | DependencyPropertyKey fields should be properly registered | ✓ | - |
| MiKo_3054 | A read-only DependencyProperty should have an exposed DependencyProperty identifier | ✓ | ✓ |
| MiKo_3055 | ViewModels should implement INotifyPropertyChanged | ✓ | - |
| MiKo_3060 | Debug.Assert or Trace.Assert shall not be used | ✓ | ✓ |
| MiKo_3061 | Loggers shall use a proper log category | ✓ | - |
| MiKo_3062 | End log messages for exceptions with a colon | ✓ | ✓ |
| MiKo_3063 | End non-exceptional log messages with a dot | ✓ | ✓ |
| MiKo_3064 | Log messages should not use the contradiction "n't" | ✓ | ✓ |
| MiKo_3070 | Do not return null for an IEnumerable | ✓ | - |
| MiKo_3071 | Do not return null for a Task | ✓ | - |
| MiKo_3072 | Non-private methods should not return 'List<>' or 'Dictionary<>' | ✓ | - |
| MiKo_3073 | Do not leave objects partially initialized | ✓ | - |
| MiKo_3074 | Do not define 'ref' or 'out' parameters on constructors | ✓ | - |
| MiKo_3075 | Internal and private types should be either static or sealed unless derivation from them is required | ✓ | ✓ |
| MiKo_3076 | Do not initialize static member with static member below or in other type part | ✓ | - |
| MiKo_3077 | Properties that return an Enum should have a default value | ✓ | ✓ |
| MiKo_3078 | Enum members should have a default value | ✓ | ✓ |
| MiKo_3079 | HResults should be written in hexadecimal | ✓ | ✓ |
| MiKo_3080 | Use 'switch ... return' instead of 'switch ... break' when assigning variables | ✓ | - |
| MiKo_3081 | Prefer pattern matching over a logical NOT condition | ✓ | ✓ |
| MiKo_3082 | Prefer pattern matching over a logical comparison with 'true' or 'false' | ✓ | ✓ |
| MiKo_3083 | Prefer pattern matching for null checks | ✓ | ✓ |
| MiKo_3084 | Do not place constants on the left side for comparisons | ✓ | ✓ |
| MiKo_3085 | Conditional statements should be short | ✓ | - |
| MiKo_3086 | Do not nest conditional statements | ✓ | - |
| MiKo_3087 | Do not use negative complex conditions | ✓ | - |
| MiKo_3090 | Do not throw exceptions in finally blocks | ✓ | - |
| MiKo_3091 | Do not raise events in finally blocks | ✓ | - |
| MiKo_3092 | Do not raise events in locks | ✓ | - |
| MiKo_3093 | Do not invoke delegates inside locks | ✓ | - |
| MiKo_3094 | Do not invoke methods or properties of parameters inside locks | ✓ | - |
| MiKo_3095 | Code blocks should not be empty | ✓ | - |
| MiKo_3096 | Use dictionaries instead of large switch statements | ✓ | - |
| MiKo_3097 | Do not cast to type and return object | ✓ | - |
| MiKo_3098 | Justifications of suppressed messages shall explain | ✓ | - |
| MiKo_3100 | Test classes and types under test belong in same namespace | ✓ | - |
| MiKo_3101 | Test classes should contain tests | ✓ | - |
| MiKo_3102 | Test methods should not contain conditional statements (such as 'if', 'switch', etc.) | ✓ | - |
| MiKo_3103 | Test methods should not use 'Guid.NewGuid()' | ✓ | ✓ |
| MiKo_3104 | Use NUnit's [Combinatorial] attribute properly | ✓ | ✓ |
| MiKo_3105 | Test methods should use NUnit's fluent Assert approach | ✓ | ✓ |
| MiKo_3106 | Assertions should not use equality or comparison operators | ✓ | - |
| MiKo_3107 | Moq Mock condition matchers should be used on mocks only | ✓ | ✓ |
| MiKo_3108 | Test methods should use assertions | ✓ | - |
| MiKo_3109 | Multiple assertions shall use assertion messages | ✓ | ✓ |
| MiKo_3110 | Assertions should not use 'Count' or 'Length' | ✓ | ✓ |
| MiKo_3111 | Assertions should use 'Is.Zero' instead of 'Is.EqualTo(0)' | ✓ | ✓ |
| MiKo_3112 | Assertions should use 'Is.Empty' instead of 'Has.Count.Zero' | ✓ | ✓ |
| MiKo_3113 | Do not use FluentAssertions | ✓ | ✓ |
| MiKo_3114 | Use 'Mock.Of<T>()' instead of 'new Mock<T>().Object' | ✓ | ✓ |
| MiKo_3115 | Test methods should contain code | ✓ | - |
| MiKo_3116 | Test initialization methods should contain code | ✓ | - |
| MiKo_3117 | Test cleanup methods should contain code | ✓ | - |
| MiKo_3118 | Test methods should not use ambiguous Linq calls | ✓ | - |
| MiKo_3201 | If statements can be inverted in short methods | ✓ | ✓ |
| MiKo_3202 | Use positive conditions when returning in all paths | ✓ | ✓ |
| MiKo_3203 | If-continue statements can be inverted when followed by single line | ✓ | ✓ |
| MiKo_3204 | Negative If statements can be inverted when they have an else clause | ✓ | ✓ |
| MiKo_3210 | Only the longest overloads should be virtual or abstract | ✓ | - |
| MiKo_3211 | Public types should not have finalizers | ✓ | - |
| MiKo_3212 | Do not confuse developers by providing other Dispose methods | ✓ | - |
| MiKo_3213 | Parameterless Dispose method follows Basic Dispose pattern | ✓ | - |
| MiKo_3214 | Interfaces do not contain 'Begin/End' or 'Enter/Exit' scope-defining methods | ✓ | - |
| MiKo_3215 | Callbacks should be 'Func<T, bool>' instead of 'Predicate<bool>' | ✓ | ✓ |
| MiKo_3216 | Static fields with initializers should be read-only | ✓ | ✓ |
| MiKo_3217 | Do not use generic types that have other generic types as type arguments | ✓ | - |
| MiKo_3218 | Do not define extension methods in unexpected places | ✓ | - |
| MiKo_3301 | Favor lambda expression bodies instead of parenthesized lambda expression blocks for single statements | ✓ | ✓ |
| MiKo_3302 | Favor simple lambda expression bodies instead of parenthesized lambda expression bodies for single parameters | ✓ | ✓ |
| MiKo_3401 | Namespace hierarchies should not be too deep | ✓ | - |
| MiKo_3501 | Do not suppress nullable warnings on Null-conditional operators | ✓ | ✓ |
| MiKo_3502 | Do not suppress nullable warnings on Linq calls | ✓ | ✓ |
Ordering
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_4001 | Methods with same name should be ordered based on the number of their parameters | ✓ | ✓ |
| MiKo_4002 | Methods with same name and accessibility should be placed side-by-side | ✓ | ✓ |
| MiKo_4003 | Dispose methods should be placed directly after constructors and finalizers | ✓ | ✓ |
| MiKo_4004 | Dispose methods should be placed before all other methods of the same accessibility | ✓ | ✓ |
| MiKo_4005 | The interface that gives a type its name should be placed directly after the type's declaration | ✓ | ✓ |
| MiKo_4101 | Test initialization methods should be ordered directly after One-Time methods | ✓ | ✓ |
| MiKo_4102 | Test cleanup methods should be ordered after test initialization methods and before test methods | ✓ | ✓ |
| MiKo_4103 | One-Time test initialization methods should be ordered before all other methods | ✓ | ✓ |
| MiKo_4104 | One-Time test cleanup methods should be ordered directly after One-Time test initialization methods | ✓ | ✓ |
Performance
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_5001 | 'Debug' and 'DebugFormat' methods should be invoked only after 'IsDebugEnabled' | ✓ | ✓ |
| MiKo_5002 | 'xxxFormat' methods should be invoked with multiple arguments only | ✓ | ✓ |
| MiKo_5003 | Correct Log methods should be invoked for exceptions | ✓ | - |
| MiKo_5010 | Do not use 'object.Equals()' on value types | ✓ | ✓ |
| MiKo_5011 | Do not concatenate strings with += operator | ✓ | - |
| MiKo_5012 | Do not use 'yield return' for recursively defined structures | ✓ | - |
| MiKo_5013 | Do not create empty arrays | ✓ | ✓ |
| MiKo_5014 | Do not create empty lists if the return value is read-only | ✓ | ✓ |
| MiKo_5015 | Do not intern string literals | ✓ | ✓ |
| MiKo_5016 | Use a HashSet for lookups in 'List.RemoveAll' | ✓ | - |
| MiKo_5017 | Fields or variables assigned with string literals should be constant | ✓ | ✓ |
Spacing
| ID | Title | Enabled by default | CodeFix available |
|---|---|---|---|
| MiKo_6001 | Log statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6002 | Assertion statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6003 | Local variable statements should be preceded by blank lines | ✓ | ✓ |
| MiKo_6004 | Variable assignment statements should be preceded by blank lines | ✓ | ✓ |
| MiKo_6005 | Return statements should be preceded by blank lines | ✓ | ✓ |
| MiKo_6006 | Awaited statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6007 | Test statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6008 | Using directives should be preceded by blank lines | ✓ | ✓ |
| MiKo_6009 | Try statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6010 | If statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6011 | Lock statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6012 | foreach loops should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6013 | for loops should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6014 | while loops should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6015 | do/while loops should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6016 | using statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6017 | switch statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6018 | break statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6019 | continue statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6020 | throw statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6021 | ArgumentNullException.ThrowIfNull statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6022 | ArgumentException.ThrowIfNullOrEmpty statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6023 | ObjectDisposedException.ThrowIf statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6030 | Open braces of initializers should be placed directly below the corresponding type definition | ✓ | ✓ |
| MiKo_6031 | Question and colon tokens of ternary operators should be placed directly below the corresponding condition | ✓ | ✓ |
| MiKo_6032 | Multi-line parameters are positioned outdented at end of method | ✓ | ✓ |
| MiKo_6033 | Braces of blocks below case sections should be placed directly below the corresponding case keyword | ✓ | ✓ |
| MiKo_6034 | Dots should be placed on same line(s) as invoked members | ✓ | ✓ |
| MiKo_6035 | Open parenthesis should be placed on same line(s) as invoked methods | ✓ | ✓ |
| MiKo_6036 | Lambda blocks should be placed directly below the corresponding arrow(s) | ✓ | ✓ |
| MiKo_6037 | Single arguments should be placed on same line(s) as invoked methods | ✓ | ✓ |
| MiKo_6038 | Casts should be placed on same line(s) | ✓ | ✓ |
| MiKo_6039 | Return values should be placed on same line(s) as return keywords | ✓ | ✓ |
| MiKo_6040 | Consecutive invocations spaning multiple lines should be aligned by their dots | ✓ | ✓ |
| MiKo_6041 | Assignments should be placed on same line(s) | ✓ | ✓ |
| MiKo_6042 | 'new' keywords should be placed on same line(s) as the types | ✓ | ✓ |
| MiKo_6043 | Expression bodies of lambdas should be placed on same line as lambda itself | ✓ | ✓ |
| MiKo_6044 | Binary operators such as '&&' or '||' should be placed on same line(s) as their right operands | ✓ | ✓ |
| MiKo_6045 | Comparisons using operators such as '==' or '!=' should be placed on same line(s) | ✓ | ✓ |
| MiKo_6046 | Calculations using operators such as '+' or '%' should be placed on same line(s) | ✓ | ✓ |
| MiKo_6047 | Braces of switch expressions should be placed directly below the corresponding switch keyword | ✓ | ✓ |
| MiKo_6048 | Logical conditions should be placed on a single line | ✓ | - |
| MiKo_6049 | Event (un-)registrations should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6050 | Multi-line arguments are positioned outdented at end of method call | ✓ | ✓ |
| MiKo_6051 | Colon of constructor call shall be placed on same line as constructor call | ✓ | ✓ |
| MiKo_6052 | Colon of list of base types shall be placed on same line as first base type | ✓ | ✓ |