MiKo Analyzers
1.0.0
Bietet Analysatoren, die auf der .NET Compiler Platform (ROSLYN) basieren und können in Visual Studio 2019 (v16.11) oder 2022 (v17.11) verwendet werden.
Wie man einen Roslyn -Analysator installiert, wird hier beschrieben.
Screenshots zur Verwendung solcher Analysatoren finden Sie hier.
In den folgenden Tabellen werden alle 473 Regeln aufgeführt, die derzeit vom Analysator bereitgestellt werden.
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_0001 | Methode ist zu groß | ✓ | - - |
| Miko_0002 | Methode ist zu komplex | ✓ | - - |
| Miko_0003 | Typ ist zu groß | ✓ | - - |
| Miko_0004 | Die Methode hat zu viele Parameter | ✓ | - - |
| Miko_0005 | Lokale Funktion ist zu groß | ✓ | - - |
| Miko_0006 | Lokale Funktion ist zu komplex | ✓ | - - |
| Miko_0007 | Lokale Funktion hat zu viele Parameter | ✓ | - - |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_1000 | "System.EventArgs" -Typen sollten mit "EventArgs" satt gemischt werden | ✓ | ✓ |
| Miko_1001 | "System.EventArgs" -Parameter sollten als "e" bezeichnet werden | ✓ | ✓ |
| Miko_1002 | Parameter sollten gemäß den Richtlinien für Event -Handler gemäß den Richtlinien für Ereignisgeräte benannt werden | ✓ | ✓ |
| Miko_1003 | Die Namensbearbeitungsmethodennamen sollten den Richtlinien für das .NET -Framework -Design folgen | ✓ | ✓ |
| Miko_1004 | Ereignisse sollten in ihren Namen keinen Begriff "Ereignis" enthalten | ✓ | ✓ |
| Miko_1005 | 'System.EventArgs' Variablen sollten ordnungsgemäß benannt werden | ✓ | ✓ |
| Miko_1006 | Ereignisse sollten 'EventHandler <t>' mit 'eventArgs' verwenden, die nach dem Ereignis benannt sind | ✓ | - - |
| Miko_1007 | Ereignisse und ihre entsprechenden "Eventargs" -Typen sollten sich im gleichen Namespace befinden | ✓ | - - |
| Miko_1008 | Die Parameter sollten gemäß den Richtlinien für das .NET Framework Design für DependentyProperty -Ereignishandler benannt werden | ✓ | ✓ |
| Miko_1009 | 'System.EventHandler' Variablen sollten ordnungsgemäß benannt werden | ✓ | ✓ |
| Miko_1010 | Methoden sollten in ihren Namen nicht "CaneExecute" oder "Ausführen" enthalten | ✓ | ✓ |
| Miko_1011 | Methoden sollten in ihren Namen nicht "Do" enthalten | ✓ | ✓ |
| Miko_1012 | Methoden sollten als "Erhöhung" anstelle von "Feuer" bezeichnet werden | ✓ | ✓ |
| Miko_1013 | Methoden sollten nicht "benachrichtigt" oder "Onnotify" genannt werden | ✓ | ✓ |
| Miko_1014 | Methoden sollten nicht mit mehrdeutiger "Scheck" benannt werden | ✓ | ✓ |
| Miko_1015 | Methoden sollten "initialisieren" anstelle von 'init' genannt werden | ✓ | ✓ |
| Miko_1016 | Fabrikmethoden sollten "erstellen" bezeichnet werden | ✓ | ✓ |
| Miko_1017 | Methoden sollten nicht mit 'get' oder 'set' vorangestellt werden, wenn von '', Can 'oder' hat 'befolgt werden, wenn sie befolgt werden. | ✓ | ✓ |
| Miko_1018 | Methoden sollten nicht mit Substantiv eines Verbs satt gemischt werden | ✓ | ✓ |
| Miko_1019 | "Clear" und "Entfernen" -Methoden sollten basierend auf ihrer Anzahl von Parametern benannt werden | ✓ | ✓ |
| Miko_1020 | Typnamen sollten begrenzt sein | - - | - - |
| Miko_1021 | Methodennamen sollten begrenzt sein | - - | - - |
| Miko_1022 | Parameternamen sollten begrenzt sein | - - | - - |
| Miko_1023 | Feldnamen sollten begrenzt sein | - - | - - |
| Miko_1024 | Eigenschaftsnamen sollten begrenzt sein | - - | - - |
| Miko_1025 | Ereignisnamen sollten begrenzt sein | - - | - - |
| Miko_1026 | Variablennamen sollten begrenzt sein | - - | - - |
| Miko_1027 | Variablennamen in Schleifen sollten begrenzt sein | - - | - - |
| Miko_1028 | Lokale Funktionsnamen sollten begrenzt sein | - - | - - |
| Miko_1030 | Die Typen sollten keinen "Zusammenfassung" oder "Basis" -Marker haben, um anzuzeigen, dass sie Basistypen sind | ✓ | ✓ |
| Miko_1031 | Entitätstypen sollten kein "Modell" -Suffix verwenden | ✓ | ✓ |
| Miko_1032 | Methoden, die sich mit Unternehmen befassen, sollten kein "Modell" als Marker verwenden | ✓ | ✓ |
| Miko_1033 | Parameter, die Entitäten darstellen | ✓ | ✓ |
| Miko_1034 | Felder, die Entitäten vertreten, sollten kein "Modell" -Suffix verwenden | ✓ | ✓ |
| Miko_1035 | Eigenschaften, die sich mit Unternehmen befassen, sollten keinen "Modell" -Marker verwenden | ✓ | ✓ |
| Miko_1036 | Ereignisse, die sich mit Unternehmen befassen, sollten keinen "Modell" -Marker verwenden | ✓ | ✓ |
| Miko_1037 | Typen sollten nicht mit "Typ", "Schnittstelle", "Klasse", "Struktur", "Aufzeichnung" oder "Enum" sattiert werden. | ✓ | ✓ |
| Miko_1038 | Klassen, die Erweiterungsmethoden enthalten, sollten mit demselben Suffix enden | ✓ | ✓ |
| Miko_1039 | Der Parameter von Erweiterungsmethoden "This" sollte einen Standardnamen haben | ✓ | ✓ |
| Miko_1040 | Die Parameter sollten nicht mit Implementierungsdetails sattiert werden | ✓ | - - |
| Miko_1041 | Felder sollten nicht mit Implementierungsdetails satt gemischt werden | ✓ | - - |
| Miko_1042 | Die Parameter von "Stornierungen" sollten einen spezifischen Namen haben | ✓ | ✓ |
| Miko_1043 | 'Stornierende' Variablen sollten einen spezifischen Namen haben | ✓ | ✓ |
| Miko_1044 | Befehle sollten mit 'Befehl' satt gemischt werden | ✓ | ✓ |
| Miko_1045 | Methoden, die durch Befehle aufgerufen werden, sollten nicht mit "Befehl" sattiert werden | ✓ | ✓ |
| Miko_1046 | Asynchrone Methoden sollten dem aufgabenbasierten asynchronen Muster folgen (TAP) | ✓ | ✓ |
| Miko_1047 | Methoden, die nicht dem aufgabenbasierten asynchronen Muster (TAP) folgen, sollten nicht darüber lügen, asynchron zu sein | ✓ | ✓ |
| Miko_1048 | Klassen, die Wertkonverter sind, sollten mit einem bestimmten Suffix enden | ✓ | ✓ |
| Miko_1049 | Verwenden Sie keine Bedarfsbedingungen wie "", "sollte", "müssen" oder "Bedarf" für Namen | ✓ | ✓ |
| Miko_1050 | Rückgabewerte sollten beschreibende Namen haben | ✓ | ✓ |
| Miko_1051 | Suffix -Parameter nicht mit Delegierten -Typen suffixen | ✓ | ✓ |
| Miko_1052 | Suffix Variablen nicht mit Delegierten -Typen | ✓ | ✓ |
| Miko_1053 | Suffix Felder nicht mit Delegierten -Typen | ✓ | ✓ |
| Miko_1054 | Nennen Sie keine Typen "Helfer" oder "Dienstprogramm" | ✓ | ✓ |
| Miko_1055 | Abhängigkeitseigenschaften sollten mit 'Eigenschaft' satt (wie im .NET -Framework) satt gemischt werden | ✓ | ✓ |
| Miko_1056 | Abhängigkeitseigenschaften sollten mit Eigenschaftsnamen vorangestellt werden (wie im .NET -Framework) | ✓ | ✓ |
| Miko_1057 | Abhängigkeits -Eigenschaftstasten sollten mit 'Schlüssel' satt (wie im .NET -Framework) satt gemischt werden | ✓ | ✓ |
| Miko_1058 | Abhängigkeits -Eigenschaftstasten sollten mit Eigenschaftsnamen vorangestellt werden (wie im .NET -Framework) | ✓ | ✓ |
| Miko_1059 | Nennen Sie die Typen "Impl" oder "Implementierung" nicht | ✓ | ✓ |
| Miko_1060 | Verwenden Sie '<entity> NotFound' anstelle von 'get <entity> fehlgeschlagen' oder '<entity> fehlend' | ✓ | ✓ |
| Miko_1061 | Der Parameter der [Out] -Methode der "Versuchsmethode] sollte spezifisch sein | ✓ | ✓ |
| Miko_1062 | 'Can/hat/enthält' Methoden, Eigenschaften oder Felder dürfen nur aus wenigen Wörtern bestehen | ✓ | - - |
| Miko_1063 | Verwenden Sie keine Abkürzungen in Namen | ✓ | ✓ |
| Miko_1064 | Parameternamen spiegeln ihre Bedeutung und nicht ihre Art wider | ✓ | - - |
| Miko_1065 | Bedienungsparameter sollten gemäß den Richtlinien für den Bediener -Überladungen von .NET Framework -Design benannt werden | ✓ | ✓ |
| Miko_1066 | Konstruktorparameter, die einer Eigenschaft zugeordnet werden, sollten nach der Eigenschaft benannt werden | ✓ | ✓ |
| Miko_1067 | Methoden sollten in ihren Namen nicht "durchführen" enthalten | ✓ | ✓ |
| Miko_1068 | Workflow -Methoden sollten als "Canrun" oder "Run" bezeichnet werden | ✓ | - - |
| Miko_1069 | Eigenschaftsnamen spiegeln ihre Bedeutung und nicht ihre Art wider | ✓ | - - |
| Miko_1070 | Lokale Sammlungsvariablen müssen den Pluralnamen verwenden | ✓ | ✓ |
| Miko_1071 | Lokale boolesche Variablen sollten als Aussagen und nicht als Fragen benannt werden | ✓ | - - |
| Miko_1072 | Boolesche Eigenschaften oder Methoden sollten als Aussagen und nicht als Fragen bezeichnet werden | ✓ | - - |
| Miko_1073 | Boolesche Felder sollten als Aussagen und nicht als Fragen benannt werden | ✓ | - - |
| Miko_1074 | Objekte, die zur Sperrung verwendet werden, sollten mit 'Sperre' satt gemischt werden | ✓ | - - |
| Miko_1075 | Nichtsystem.EventArgs-Typen sollten nicht mit 'eventArgs' sattiert werden. | ✓ | ✓ |
| Miko_1076 | PRISM -Ereignisarten sollten mit "Ereignis" sattiert werden | ✓ | ✓ |
| Miko_1077 | Enum -Mitglieder sollten nicht mit "Enum" sattiert werden | ✓ | ✓ |
| Miko_1078 | Die Namensnamen für Builder -Methoden sollten mit "Build" beginnen | ✓ | ✓ |
| Miko_1079 | Repositorys sollten nicht mit "Repository" sattiert werden | ✓ | ✓ |
| Miko_1080 | Namen sollten Zahlen anstelle ihrer Schreibweisen enthalten | ✓ | - - |
| Miko_1081 | Methoden sollten nicht mit einer Zahl satt gemischt werden | ✓ | ✓ |
| Miko_1082 | Immobilien sollten nicht mit einer Zahl satt werden, wenn ihre Typen Zahlensuffixen haben | ✓ | ✓ |
| Miko_1083 | Felder sollten nicht mit einer Zahl satt werden, wenn ihre Typen Zahlensuffix haben | ✓ | ✓ |
| Miko_1084 | Variablen sollten nicht mit einer Zahl satt werden, wenn ihre Typen Zahlensuffixen haben | ✓ | ✓ |
| Miko_1085 | Die Parameter sollten nicht mit einer Zahl satt gemischt werden | ✓ | ✓ |
| Miko_1086 | Methoden sollten nicht mit Zahlen als Slang benannt werden | ✓ | - - |
| Miko_1087 | Name Konstruktorparameter nach ihren Gegenstücken in der Basisklasse | ✓ | ✓ |
| Miko_1088 | Singleton -Instanzen sollten als "Instanz" bezeichnet werden | ✓ | - - |
| Miko_1089 | Methoden sollten nicht mit 'get' vorangestellt werden | ✓ | ✓ |
| Miko_1090 | Die Parameter sollten nicht mit bestimmten Typen satt gemischt werden | ✓ | ✓ |
| Miko_1091 | Variablen sollten nicht mit bestimmten Typen satt gemischt werden | ✓ | ✓ |
| Miko_1092 | 'Fähigkeitstypen sollte nicht mit redundanten Informationen sattiert werden | ✓ | ✓ |
| Miko_1093 | Verwenden Sie das Suffix 'Objekt' oder 'Struct' nicht | ✓ | ✓ |
| Miko_1094 | Suffix -Typen nicht mit passiven Namespace -Namen suffixen | ✓ | - - |
| Miko_1095 | Verwenden Sie nicht 'Löschen' und 'entfernen' sowohl in Namen als auch in Dokumentation | ✓ | - - |
| Miko_1096 | Namen sollten "fehlgeschlagen" anstelle von "notsuccessful" verwenden | ✓ | - - |
| Miko_1097 | Parameternamen sollten nicht dem Namensschema für Felder folgen | ✓ | ✓ |
| Miko_1098 | Typamen sollten die von ihnen implementierenden Geschäftsschnittstellen widerspiegeln | ✓ | - - |
| Miko_1099 | Übereinstimmende Parameter auf Methodenüberladungen sollten identische Namen haben | ✓ | ✓ |
| Miko_1100 | Testklassen sollten mit dem Namen des zu testenden Typs beginnen | ✓ | - - |
| Miko_1101 | Testklassen sollten mit "Tests" enden | ✓ | ✓ |
| Miko_1102 | Testmethoden sollten in ihren Namen nicht "Test" enthalten | ✓ | ✓ |
| Miko_1103 | Testinitialisierungsmethoden sollten als "preparetest" bezeichnet werden | ✓ | ✓ |
| Miko_1104 | Testbereinigungsmethoden sollten als "Cleanuptest" bezeichnet werden | ✓ | ✓ |
| Miko_1105 | Einmalige Testinitialisierungsmethoden sollten als "Präparatedum" bezeichnet werden. | ✓ | ✓ |
| Miko_1106 | Einmalige Testbereinigungsmethoden sollten als "CleanupteTenvironment" bezeichnet werden. | ✓ | ✓ |
| Miko_1107 | Testmethoden sollten nicht in Pascal-Casing erfolgen | ✓ | ✓ |
| Miko_1108 | Nennen Sie keine Variablen, Parameter, Felder und Eigenschaften "Mock", "Stub", "Fake" oder "Shim" | ✓ | ✓ |
| Miko_1109 | Präfix prüfbare Typen mit "Testable" anstatt das UT -Suffix zu verwenden | ✓ | ✓ |
| Miko_1110 | Testmethoden mit Parametern sollten mit Unterstriche satt gemischt werden | ✓ | ✓ |
| Miko_1111 | Testmethoden ohne Parameter sollten nicht mit Unterstrich sattiert werden | ✓ | ✓ |
| Miko_1112 | Nennen Sie die Testdaten nicht "willkürlich" | ✓ | ✓ |
| Miko_1113 | Testmethoden sollten nicht im BDD -Stil benannt werden | ✓ | - - |
| Miko_1114 | Testmethoden sollten nicht als "Happypath" oder "Bad Path" bezeichnet werden | ✓ | - - |
| Miko_1115 | Testmethoden sollten fließend benannt werden | ✓ | ✓ |
| Miko_1200 | Nennen Sie Ausnahmen in Fangblöcken konsequent | ✓ | ✓ |
| Miko_1201 | Nennen Sie Ausnahmen als Parameter konsistent | ✓ | ✓ |
| Miko_1300 | Unwichtige Identifikatoren in Lambda -Aussagen sollten "_" bezeichnet werden | ✓ | ✓ |
| Miko_1400 | Namespace -Namen sollten in Plural sein | ✓ | - - |
| Miko_1401 | Namespaces sollten keine technischen Sprachnamen enthalten | ✓ | - - |
| Miko_1402 | Namespaces sollten nicht nach WPF-spezifischen Entwurfsmustern benannt werden | ✓ | - - |
| Miko_1403 | Namespaces sollten nicht nach einem ihrer übergeordneten Namespaces benannt werden | ✓ | - - |
| Miko_1404 | Namespaces sollten nicht unspezifische Namen enthalten | ✓ | - - |
| Miko_1405 | Namespaces sollten nicht "lib" enthalten | ✓ | - - |
| Miko_1406 | Wertkonverter sollten in den Namespace "Konverters" platziert werden | ✓ | - - |
| Miko_1407 | Test -Namespaces sollten nicht "Test" enthalten | ✓ | - - |
| Miko_1408 | Erweiterungsmethoden sollten in denselben Namespace wie die erweiterten Typen platziert werden | ✓ | - - |
| Miko_1409 | Präfix- oder Suffix -Namespaces mit Unterstrichen nicht | ✓ | - - |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_2000 | Die Dokumentation sollte gültig sein XML | ✓ | ✓ |
| Miko_2001 | Ereignisse sollten ordnungsgemäß dokumentiert werden | ✓ | ✓ |
| Miko_2002 | EventArgs sollten ordnungsgemäß dokumentiert werden | ✓ | ✓ |
| Miko_2003 | Die Dokumentation von Ereignishandlern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2004 | Die Dokumentation der Parameternamen des Ereignishandlers sollten .NET Framework Design -Richtlinien für Ereignishandler folgen | ✓ | ✓ |
| Miko_2005 | Textverweise auf EventArgs sollten ordnungsgemäß dokumentiert werden | ✓ | - - |
| Miko_2006 | Routed -Ereignisse sollten wie vom .NET -Framework dokumentiert werden | ✓ | ✓ |
| Miko_2010 | Versiegelte Klassen sollten dokumentieren, die versiegelt werden | ✓ | ✓ |
| Miko_2011 | Nicht versiegelte Klassen sollten nicht über die Versiegelung lügen | ✓ | ✓ |
| Miko_2012 | <summary> Dokumentation sollte die Verantwortung des Typs beschreiben | ✓ | ✓ |
| Miko_2013 | <summary> Dokumentation von Enums sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2014 | Entsorgen Sie die Methoden sollten wie im .NET -Framework dokumentiert werden | ✓ | ✓ |
| Miko_2015 | Die Dokumentation sollte "Erhöhung" oder "werfen" anstelle von "Feuer" verwenden | ✓ | ✓ |
| Miko_2016 | Die Dokumentation für asynchrone Methoden sollte mit spezifischem Satz beginnen | ✓ | ✓ |
| Miko_2017 | Abhängigkeitseigenschaften sollten wie im .NET -Framework dokumentiert werden | ✓ | ✓ |
| Miko_2018 | Die Dokumentation sollte nicht die mehrdeutigen Begriffe "Scheck" oder "Test" verwenden | ✓ | ✓ |
| Miko_2019 | <summary> Dokumentation sollte mit einem Singularverb der dritten Person beginnen (z. B. "Angebote")) | ✓ | - - |
| Miko_2020 | Die ererbte Dokumentation sollte mit <inheritdoc /> Marker verwendet werden | ✓ | ✓ |
| Miko_2021 | Die Dokumentation des Parameters sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2022 | Die Dokumentation von [Out] -Parametern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2023 | Die Dokumentation von Booleschen Parametern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2024 | Die Dokumentation von Enum -Parametern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2025 | Die Dokumentation der Parameter von "Stornierungen" sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2026 | Verwendete Parameter sollten nicht als ungenutzt dokumentiert werden | ✓ | - - |
| Miko_2027 | Serialisierungskonstruktorparameter sind mit einem bestimmten Ausdruck dokumentiert | ✓ | ✓ |
| Miko_2028 | Die Dokumentation des Parameters sollte nicht nur den Namen des Parameters enthalten | ✓ | - - |
| Miko_2029 | <Nheritdoc> Dokumentation sollte kein 'Cref' für sich selbst verwenden | ✓ | ✓ |
| Miko_2030 | Die Dokumentation des Rückgabewerts sollte einen Standard -Startphrase haben | ✓ | - - |
| Miko_2031 | Die Dokumentation des Aufgabenrückgabewerts sollte eine spezifische (Start-) Phrase haben | ✓ | ✓ |
| Miko_2032 | Die Dokumentation des Booleschen Rückgabewerts sollte einen bestimmten Satz haben | ✓ | ✓ |
| Miko_2033 | Die Dokumentation des String -Rückgabewerts sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2034 | Die Dokumentation des Enum -Rückgabewerts sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2035 | Die Dokumentation des Sammlungsrückgabewerts sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2036 | Die Dokumentation von Boolean oder Enum -Eigentum beschreibt den Standardwert | ✓ | ✓ |
| Miko_2037 | <summary> Dokumentation der Befehlseigenschaften sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2038 | <summary> Dokumentation des Befehls sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2039 | <summary> Dokumentation von Klassen, die Erweiterungsmethoden enthalten | ✓ | ✓ |
| Miko_2040 | <siehe langword = "..."/> sollte anstelle von <c> ... </c> verwendet werden | ✓ | ✓ |
| Miko_2041 | <summary> Dokumentation sollte keine anderen Dokumentations -Tags enthalten | ✓ | ✓ |
| Miko_2042 | Dokumentation sollte '<para/>' XML -Tags anstelle von '<br/>' HTML -Tags verwenden | ✓ | ✓ |
| Miko_2043 | <summary> Dokumentation benutzerdefinierter Delegierter sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2044 | Dokumentationsreferenzen Methodenparameter richtig | ✓ | ✓ |
| Miko_2045 | <summary> Dokumentation sollte keine Referenzparameter verweisen | ✓ | ✓ |
| Miko_2046 | Die Dokumentation sollte die Referenztypparameter korrekt | ✓ | ✓ |
| Miko_2047 | <summary> Dokumentation von Attributen sollte einen Standard -Startphrase haben | ✓ | - - |
| Miko_2048 | <summary> Dokumentation von Wertkonvertern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2049 | Die Dokumentation sollte expliziter sein und nicht "Sein" verwendet wird | ✓ | ✓ |
| Miko_2050 | Ausnahmen sollten nach dem .NET -Framework dokumentiert werden | ✓ | ✓ |
| Miko_2051 | Die geworfenen Ausnahmen sollten als eine Art Bedingung dokumentiert werden (z. B. '<paramref name = "xyz"/> ist <c> 42 </c>') | ✓ | ✓ |
| Miko_2052 | Das Werfen von ArgumentNulLexception sollte unter Verwendung einer Standardphrase dokumentiert werden | ✓ | ✓ |
| Miko_2053 | Das Werfen von ArgumentNulLexception sollte nur für Referenztypparameter dokumentiert werden | ✓ | - - |
| Miko_2054 | Das Werfen von ArgumentException sollte unter Verwendung eines Standard -Startphrase dokumentiert werden | ✓ | ✓ |
| Miko_2055 | Das Werfen von ArgumentoutoFrangeException sollte unter Verwendung einer Standard -Startphrase dokumentiert werden | ✓ | ✓ |
| Miko_2056 | Das Werfen von ObjectDisposedException sollte unter Verwendung einer Standard -End -Phrase dokumentiert werden | ✓ | ✓ |
| Miko_2057 | Typen, die nicht verfügbar sind | ✓ | ✓ |
| Miko_2059 | Mehrere Dokumentation derselben Ausnahme sollte in einem konsolidiert werden | ✓ | ✓ |
| Miko_2060 | Fabriken sollten auf einheitliche Weise dokumentiert werden | ✓ | ✓ |
| Miko_2070 | <summary> Dokumentation sollte nicht mit 'Rückgaben' beginnen | ✓ | ✓ |
| Miko_2071 | <summary> Dokumentation für Methoden, die Enumtypen zurückgeben, sollte keine Phrase für den Booleschen Typ enthalten | ✓ | - - |
| Miko_2072 | <summary> Dokumentation sollte nicht mit 'Versuch' beginnen | ✓ | ✓ |
| Miko_2073 | <summary> Dokumentation von 'enthaltenden' Methoden sollten mit 'bestimmt, ob' starten sollten | ✓ | ✓ |
| Miko_2074 | Die Dokumentation des Parameters der "enthaltenden" Methode sollte einen Standard -Endphrase haben | ✓ | ✓ |
| Miko_2075 | Die Dokumentation sollte den Begriff "Rückruf" anstelle von "Aktion", "Func" oder "Funktion" verwenden | ✓ | ✓ |
| Miko_2076 | Dokumentation sollte die Standardwerte der optionalen Parameter dokumentieren | ✓ | ✓ |
| Miko_2077 | <summary> Dokumentation sollte nicht <code> enthalten | ✓ | - - |
| Miko_2078 | <code> Dokumentation sollte keine XML -Tags enthalten | ✓ | - - |
| Miko_2079 | <summary> Dokumentation der Eigenschaften sollte keinen offensichtlichen Text haben | ✓ | ✓ |
| Miko_2080 | <summary> Dokumentation von Feldern sollte einen Standard -Startphrase haben | ✓ | ✓ |
| Miko_2081 | <summary> Dokumentation von öffentlich zugänglichen schreibgeschützten Feldern sollte einen Standard-Endphrase haben | ✓ | ✓ |
| Miko_2082 | <summary> Dokumentation von Enum -Mitgliedern sollte nicht mit Standard -Startphrasen der Enum <summary> Dokumentation beginnen | ✓ | ✓ |
| Miko_2090 | Die Dokumentation für den Gleichstellungsbetreiber hat eine Standardausstellung | ✓ | ✓ |
| Miko_2091 | Die Dokumentation für den Ungleichheitsbetreiber hat einen Standardphrase | ✓ | ✓ |
| Miko_2100 | <Beispiel> Die Dokumentation sollte mit beschreibender Standardphrase beginnen | ✓ | ✓ |
| Miko_2101 | <Beispiel> Dokumentation sollte Codebeispiel in <Code> Tags anzeigen | ✓ | ✓ |
| Miko_2200 | Verwenden Sie einen kapitalisierten Brief, um den Kommentar zu starten | ✓ | ✓ |
| Miko_2201 | Verwenden Sie einen kapitalisierten Brief, um die Sätze im Kommentar zu starten | ✓ | - - |
| Miko_2202 | Die Dokumentation sollte den Begriff "Kennung" anstelle von "ID" verwenden | ✓ | ✓ |
| Miko_2203 | Die Dokumentation sollte den Begriff "eindeutiger Kenner" anstelle von "Guid" verwenden | ✓ | ✓ |
| Miko_2204 | Die Dokumentation sollte <List> für Aufzählungen verwenden | ✓ | ✓ |
| Miko_2205 | Die Dokumentation sollte <Note> für wichtige Informationen verwenden | ✓ | - - |
| Miko_2206 | Die Dokumentation sollte den Begriff "Flag" nicht verwenden | ✓ | - - |
| Miko_2207 | <summary> Dokumentation ist kurz zu sein | ✓ | - - |
| Miko_2208 | Die Dokumentation sollte den Begriff "eine Instanz von" nicht verwenden | ✓ | ✓ |
| Miko_2209 | Verwenden Sie keine Doppelperioden in der Dokumentation | ✓ | ✓ |
| Miko_2210 | Die Dokumentation sollte den Begriff "Informationen" anstelle von "Info" verwenden | ✓ | ✓ |
| Miko_2211 | Enum -Mitglieder sollten keine Abschnitte <bemerkungen> haben | ✓ | ✓ |
| Miko_2212 | Die Dokumentation sollte den Ausdruck "fehlgeschlagen" anstelle von "war nicht erfolgreich" verwenden. | ✓ | ✓ |
| Miko_2213 | Die Dokumentation sollte die Kontraktion "n't" nicht verwenden | ✓ | ✓ |
| Miko_2214 | Die Dokumentation sollte keine leeren Zeilen enthalten | ✓ | ✓ |
| Miko_2215 | Sätze in der Dokumentation sind kurz zu sein | ✓ | - - |
| Miko_2216 | Verwenden | ✓ | ✓ |
| Miko_2217 | <List> Die Dokumentation erfolgt ordnungsgemäß | ✓ | ✓ |
| Miko_2218 | Die Dokumentation sollte kürzere Begriffe anstelle von längerfristig "verwendet werden"/in/by "verwenden | ✓ | ✓ |
| Miko_2219 | Verwenden Sie keine Frage- oder Erkundungsmarken in der Dokumentation | ✓ | - - |
| Miko_2220 | Dokumentation sollte "suchen" anstelle von "nach" suchen "," für "oder" testen "zu inspizieren oder für" auf zu testen " | ✓ | ✓ |
| Miko_2221 | Die Dokumentation sollte keine leeren XML -Tags verwenden | ✓ | - - |
| Miko_2222 | Dokumentation sollte den Begriff "Identifikation" anstelle von "Identifizierung" verwenden | ✓ | ✓ |
| Miko_2223 | Dokumentation verlinkt Referenzen über <siehe cref = "..."/> | ✓ | - - |
| Miko_2224 | Die Dokumentation sollte XML -Tags und Texte in separaten Zeilen platziert haben | ✓ | ✓ |
| Miko_2225 | Der mit <c> Tags gekennzeichnete Code sollte in einzelnen Zeile platziert werden | ✓ | ✓ |
| Miko_2226 | Die Dokumentation sollte das "Warum" und nicht das "das" erklären | ✓ | - - |
| Miko_2227 | Die Dokumentation sollte keine Resharper -Unterdrückung enthalten | ✓ | - - |
| Miko_2228 | Die Dokumentation sollte positiven Wortlaut anstelle von negativen verwenden | ✓ | - - |
| Miko_2229 | Die Dokumentation sollte keine linksübergreifenden XML-Fragmente enthalten | ✓ | ✓ |
| Miko_2231 | Dokumentation von überschriebenes 'Gethashcode ()' Methoden muss '<inheritdoc />' Marker verwendet | ✓ | ✓ |
| Miko_2232 | <summary> Dokumentation sollte nicht leer sein | ✓ | ✓ |
| Miko_2233 | XML -Tags sollten auf einzelnen Linien platziert werden | ✓ | ✓ |
| Miko_2300 | Kommentare sollten das "Warum" und nicht das "Wie" erklären | ✓ | - - |
| Miko_2301 | Verwenden Sie keine offensichtlichen Kommentare in AAA-Tests | ✓ | ✓ |
| Miko_2302 | Behalten Sie keinen Code, der kommentiert wird | ✓ | - - |
| Miko_2303 | Beenden Sie keine Kommentare mit einem Zeitraum | ✓ | ✓ |
| Miko_2304 | Formulieren Sie keine Kommentare als Fragen | ✓ | - - |
| Miko_2305 | Verwenden Sie in Kommentaren keine Doppelperioden | ✓ | ✓ |
| Miko_2306 | Beenden Kommentare mit einer Periode | - - | - - |
| Miko_2307 | Kommentare sollten den Ausdruck "fehlgeschlagen" anstelle von "war nicht erfolgreich" verwenden. | ✓ | ✓ |
| Miko_2308 | Stellen Sie keine Kommentare zur einzelnen Zeile vor, bevor Sie die Klammer schließen, sondern nach Code | ✓ | ✓ |
| Miko_2309 | Kommentare sollten die Kontraktion "n't" nicht verwenden | ✓ | ✓ |
| Miko_2310 | Kommentare sollten das "Warum" und nicht das "das" erklären | ✓ | - - |
| Miko_2311 | Verwenden Sie keine Trennzeichenkommentare | ✓ | ✓ |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_3000 | Verwenden Sie keine leeren Regionen | ✓ | - - |
| Miko_3001 | Benutzerdefinierte Delegierte sollten nicht verwendet werden | ✓ | - - |
| Miko_3002 | Klassen sollten nicht zu viele Abhängigkeiten haben | ✓ | - - |
| Miko_3003 | Ereignisse sollten den Richtlinien für Ereignisse von .NET Framework Design folgen | ✓ | - - |
| Miko_3004 | Immobiliensetzer von EventArgs müssen privat sein | ✓ | - - |
| Miko_3005 | Methoden mit dem Namen "Try" sollten dem Trier-Doer-Muster folgen | ✓ | - - |
| Miko_3006 | Der Parameter "Stornierkörpertoken" sollte der letzte Methodeparameter sein | ✓ | - - |
| Miko_3007 | Verwenden Sie keine LINQ -Methode und die deklarative Abfrage -Syntax in derselben Methode | ✓ | - - |
| Miko_3008 | Die Methode sollte keine Kollektionen zurückgeben, die von außen geändert werden können | ✓ | - - |
| Miko_3009 | Befehle sollten nur benannte Methoden und keine Lambda -Ausdrücke aufrufen | ✓ | - - |
| Miko_3010 | Erstellen oder werfen Sie reservierte Ausnahmetypen nicht | ✓ | - - |
| Miko_3011 | Die geworfenen ArgumentExceptions (oder deren Subtypen) liefern den richtigen Parameternamen | ✓ | ✓ |
| Miko_3012 | Die geworfenen ArgumentoutofrangeExceptions (oder deren Subtypen) liefern den tatsächlichen Wert, der die Ausnahme verursacht | ✓ | ✓ |
| Miko_3013 | Die Standardklausel in 'Switch' -Anweisungen sollte ein ArgumentoutoFrangeException (oder Subtyp) werfen, aber keine ArgumentationException | ✓ | ✓ |
| Miko_3014 | InvalidOperationException, NotimplementedException und NotSupportedException sollten einen Grund als Nachricht haben | ✓ | ✓ |
| Miko_3015 | Werfen Sie InvalidOperationExceptions (anstelle von ArgumentExceptions oder deren Subtypen), um unangemessene Zustände parameterloser Methoden anzuzeigen | ✓ | ✓ |
| Miko_3016 | Werfen Sie keine Argumentnullexception für unangemessene Zustände der Eigenschaftsrenditewerte | ✓ | ✓ |
| Miko_3017 | Schlucken Sie keine Ausnahmen, wenn Sie neue Ausnahmen werfen | ✓ | ✓ |
| Miko_3018 | Werfen Sie ObjectDispontedExceptions auf öffentlich sichtbare Methoden der Einweg -Typen | ✓ | - - |
| Miko_3020 | Verwenden Sie 'Task.com pletedTask' anstelle von 'task.fromResult' 'anstelle von' task.fromResult ' | ✓ | ✓ |
| Miko_3021 | Verwenden Sie in der Implementierung nicht 'Task.run' | ✓ | - - |
| Miko_3022 | Geben Sie die Aufgabe nicht zurück. | ✓ | - - |
| Miko_3023 | Verwenden Sie keine "StornierungTokenSource" als Parameter | ✓ | - - |
| Miko_3024 | Verwenden Sie nicht das Schlüsselwort [Ref] für Referenzparameter | ✓ | - - |
| Miko_3025 | Methodenparameter nicht neu zugänglich machen | ✓ | - - |
| Miko_3026 | Nicht verwendete Parameter sollten entfernt werden | ✓ | - - |
| Miko_3027 | Parameter sollten nicht als reserviert für die zukünftige Nutzung reserviert werden | ✓ | - - |
| Miko_3028 | Weisen Sie Lambda -Parametern Null nicht zu | ✓ | - - |
| Miko_3029 | Ereignisregistrierungen sollten keine Speicherlecks verursachen | ✓ | - - |
| Miko_3030 | Methoden sollten dem Gesetz des Demeters folgen | - - | - - |
| Miko_3031 | Iclonable.clone () sollte nicht implementiert werden | ✓ | - - |
| Miko_3032 | Verwenden Sie 'Nameof' anstelle von Cinch für Namen von Eigenschaften für erstellte 'PropertyChangeDeDargs' Instanzen | ✓ | ✓ |
| Miko_3033 | Verwenden Sie 'Nameof' für Namen von Eigenschaften für erstellte 'PropertyChangingEventArgs' und 'PropertyChangeDeDargs' Instanzen | ✓ | ✓ |
| Miko_3034 | Property Charged Event Raise wird [CallmemberName] Attribut verwendet | ✓ | ✓ |
| Miko_3035 | Rufen Sie keine "Waitone" -Methoden ohne Timeouts auf | ✓ | - - |
| Miko_3036 | Verwenden Sie lieber "Timesspan" -Fabrikmethoden anstelle von Konstruktoren | ✓ | ✓ |
| Miko_3037 | Verwenden Sie keine magischen Zahlen für Zeitüberschreitungen | ✓ | - - |
| Miko_3038 | Verwenden Sie keine magischen Zahlen | ✓ | - - |
| Miko_3039 | Eigenschaften sollten keine LINQ oder Ertrag verwenden | ✓ | - - |
| Miko_3040 | Verwenden Sie Booleans nicht, es sei denn, Sie sind absolut sicher, dass Sie niemals mehr als 2 Werte benötigen werden | ✓ | - - |
| Miko_3041 | EventArgs dürfen keine Delegierten verwenden | ✓ | - - |
| Miko_3042 | EventArgs dürfen keine Schnittstellen implementieren | ✓ | - - |
| Miko_3043 | Verwenden Sie 'Nameof' für WeakeVventManager-Event (DE-) Registrierungen | ✓ | ✓ |
| Miko_3044 | Verwenden Sie 'Nameof', um Eigenschaftsnamen von 'PropertyChangingEventArgs' und 'PropertyChangeDeDargs' zu vergleichen. | ✓ | ✓ |
| Miko_3045 | Verwenden Sie 'Nameof' für EventManager -Ereignisregistrierungen | ✓ | ✓ |
| Miko_3046 | Verwenden Sie 'Nameof' für Eigenschaftsnamen von Eigentumsbeschaffungsmethoden | ✓ | ✓ |
| Miko_3047 | Verwenden Sie 'nameof' für angewandte [contentProperty] -attribute | ✓ | ✓ |
| Miko_3048 | Wertschöpfungsstörungen haben das Attribut für [Wertschöpfung] angewendet | ✓ | - - |
| Miko_3049 | Die Aufzündungsmitglieder haben das Attribut [Beschreibung] angewendet | ✓ | - - |
| Miko_3050 | Die Felder von DependentyProperty sollten "öffentliches statisches Readonly" sein | ✓ | ✓ |
| Miko_3051 | Die Felder von DependentyProperty sollten ordnungsgemäß registriert sein | ✓ | ✓ |
| Miko_3052 | DependentyPropertyKey-Felder sollten nicht öffentlich "statisch readonly" sein | ✓ | ✓ |
| Miko_3053 | Die Felder von DependentyPropertyKey sollten ordnungsgemäß registriert sein | ✓ | - - |
| Miko_3054 | Eine schreibgeschützte Abhängigkeitspflicht sollte eine exponierte Abhängigkeitspflicht-Kennung haben | ✓ | ✓ |
| Miko_3055 | ViewModels sollten InotifyPropertyChanged implementieren | ✓ | - - |
| Miko_3060 | Debug.assert oder Trace.assert darf nicht verwendet werden | ✓ | ✓ |
| Miko_3061 | Holzfäller müssen eine ordnungsgemäße Protokollkategorie verwenden | ✓ | - - |
| Miko_3062 | Endprotokollnachrichten für Ausnahmen mit einem Dickdarm | ✓ | ✓ |
| Miko_3063 | Beenden Sie nicht nützliche Protokollnachrichten mit einem Punkt | ✓ | ✓ |
| Miko_3064 | Protokollnachrichten sollten die Kontraktion "n't" nicht verwenden | ✓ | ✓ |
| Miko_3065 | Microsoft -Protokollierungsaufrufe sollten keine interpolierten Zeichenfolgen verwenden | ✓ | ✓ |
| Miko_3070 | Kehren Sie Null nicht für ein Ienumerable zurück | ✓ | - - |
| Miko_3071 | Kehren Sie Null für eine Aufgabe nicht zurück | ✓ | - - |
| Miko_3072 | Nicht private Methoden sollten nicht 'Liste <>' oder 'Dictionary <>' zurückgeben. | ✓ | - - |
| Miko_3073 | Lassen Sie die Objekte nicht teilweise initialisiert | ✓ | - - |
| Miko_3074 | Definieren Sie die Parameter von 'Ref' oder 'out' bei Konstruktoren nicht | ✓ | - - |
| Miko_3075 | Interne und private Typen sollten entweder statisch oder versiegelt sein, sofern keine Ableitung von ihnen erforderlich ist | ✓ | ✓ |
| Miko_3076 | Initialisieren Sie kein statisches Mitglied mit statischer Mitglied unten oder in einem anderen Typ Teil | ✓ | - - |
| Miko_3077 | Eigenschaften, die einen Enum zurückgeben, sollten einen Standardwert haben | ✓ | ✓ |
| Miko_3078 | Enum -Mitglieder sollten einen Standardwert haben | ✓ | ✓ |
| Miko_3079 | Hresults sollten in Hexadezimal geschrieben werden | ✓ | ✓ |
| Miko_3080 | Verwenden Sie 'Switch ... zurück' anstelle von 'Switch ... Break', wenn Variablen zugewiesen werden | ✓ | - - |
| Miko_3081 | Bevorzugen | ✓ | ✓ |
| Miko_3082 | Bevorzugen Sie das Muster, das über einen logischen Vergleich mit 'true' oder 'false' übereinstimmt. | ✓ | ✓ |
| Miko_3083 | Bevorzugen Sie das Muster -Matching für Nullprüfungen | ✓ | ✓ |
| Miko_3084 | Platzieren Sie keine Konstanten auf der linken Seite für Vergleiche | ✓ | ✓ |
| Miko_3085 | Bedingte Aussagen sollten kurz sein | ✓ | - - |
| Miko_3086 | Nestieren Sie keine bedingten Aussagen | ✓ | - - |
| Miko_3087 | Verwenden Sie keine negativen komplexen Bedingungen | ✓ | - - |
| Miko_3088 | Bevorzugen | ✓ | ✓ |
| Miko_3089 | Verwenden Sie keine einfachen konstanten Eigenschaftsmuster als Bedingungen von 'if' Anweisungen | ✓ | ✓ |
| Miko_3090 | Werfen Sie keine Ausnahmen in endgültigen Blöcken | ✓ | - - |
| Miko_3091 | Erhöhen Sie keine Ereignisse in endgültigen Blöcken | ✓ | - - |
| Miko_3092 | Erhöhen Sie keine Ereignisse in Schlössern | ✓ | - - |
| Miko_3093 | Rufen Sie Delegierte in Schlösser nicht auf | ✓ | - - |
| Miko_3094 | Rufen Sie keine Methoden oder Eigenschaften von Parametern in Schlösser auf | ✓ | - - |
| Miko_3095 | Codeblöcke sollten nicht leer sein | ✓ | - - |
| Miko_3096 | Verwenden Sie Wörterbücher anstelle von großen Switch -Anweisungen | ✓ | - - |
| Miko_3097 | Nicht zum Eingeben und Rückgabeboto abgeben und das Objekt zurückgeben | ✓ | - - |
| Miko_3098 | Begründungen unterdrückter Nachrichten müssen erklären | ✓ | - - |
| Miko_3099 | Vergleichen Sie die Enum -Werte nicht mit NULL | ✓ | ✓ |
| Miko_3100 | Die untersuchten Testklassen und -Typen gehören in denselben Namespace | ✓ | - - |
| Miko_3101 | Testklassen sollten Tests enthalten | ✓ | - - |
| Miko_3102 | Testmethoden sollten keine bedingten Aussagen enthalten (z. B. 'if', 'switch' usw.) | ✓ | - - |
| Miko_3103 | Testmethoden sollten nicht 'Guid.Newguid ()' verwenden. | ✓ | ✓ |
| Miko_3104 | Verwenden Sie das [kombinatorische] Attribut von Nunit ordnungsgemäß | ✓ | ✓ |
| Miko_3105 | Testmethoden sollten den fließenden Ansatz von Nunits Fluent Assert verwenden | ✓ | ✓ |
| Miko_3106 | Behauptungen dürfen keine Gleichstellung oder Vergleichsbetreiber verwenden | ✓ | - - |
| Miko_3107 | MOQ Mock Condition Matcher sollten nur bei Mocks verwendet werden | ✓ | ✓ |
| Miko_3108 | Testmethoden sollten Behauptungen verwenden | ✓ | - - |
| Miko_3109 | Mehrere Behauptungen verwenden Assertion -Nachrichten | ✓ | ✓ |
| Miko_3110 | Behauptungen sollten nicht "zählen" oder "Länge" verwenden | ✓ | ✓ |
| Miko_3111 | Behauptungen sollten "IS.Zero" anstelle von "is.equalto (0)" verwenden. | ✓ | ✓ |
| Miko_3112 | Behauptungen sollten "IS.Empty" anstelle von "has.count.zero" verwenden. | ✓ | ✓ |
| Miko_3113 | Verwenden Sie keine Fluentassertionen | ✓ | ✓ |
| Miko_3114 | Verwenden Sie 'mock.of <t> ()' anstelle von 'New Mock <T> (). Objekt' ' | ✓ | ✓ |
| Miko_3115 | Testmethoden sollten Code enthalten | ✓ | - - |
| Miko_3116 | Testinitialisierungsmethoden sollten Code enthalten | ✓ | - - |
| Miko_3117 | Testbereinigungsmethoden sollten Code enthalten | ✓ | - - |
| Miko_3118 | Testmethoden sollten keine mehrdeutigen LINQ -Aufrufe verwenden | ✓ | - - |
| Miko_3119 | Testmethoden sollten nicht einfach die abgeschlossene Aufgabe zurückgeben | ✓ | ✓ |
| Miko_3120 | MOQ -Mocks sollten Werte anstelle von 'it.is <> (...)' Bedingungs -Matriper verwenden, um die genauen Werte zu überprüfen | ✓ | ✓ |
| Miko_3121 | Tests sollten konkrete Implementierungen und keine Schnittstellen testen | ✓ | - - |
| Miko_3122 | Testmethoden sollten nicht mehr als 2 Parameter verwenden | ✓ | - - |
| Miko_3201 | Wenn Aussagen in kurzen Methoden invertiert werden können | ✓ | ✓ |
| Miko_3202 | Verwenden Sie positive Bedingungen, wenn Sie auf allen Pfaden zurückkehren | ✓ | ✓ |
| Miko_3203 | Wenn Sie an die Aussagen sind, können Sie invertiert werden, wenn sie von einer einzelnen Zeile gefolgt werden | ✓ | ✓ |
| Miko_3204 | Negativ, wenn Aussagen invertiert werden können, wenn sie eine andere Klausel haben | ✓ | ✓ |
| Miko_3210 | Nur die längsten Überladungen sollten virtuell oder abstrakt sein | ✓ | - - |
| Miko_3211 | Öffentliche Typen sollten keine Finalizer haben | ✓ | - - |
| Miko_3212 | Verwechseln Sie Entwickler nicht, indem Sie andere Entsendung Methoden bereitstellen | ✓ | - - |
| Miko_3213 | Parameterlose Entsendung Methode folgt dem grundlegenden Entsendungsmuster | ✓ | - - |
| Miko_3214 | Schnittstellen enthalten keine "Beginn/End" oder "Enter/Exit" -Methodendefinierungsmethoden | ✓ | - - |
| Miko_3215 | Rückrufe sollten 'func <t, bool>' anstelle von 'Predicate <bool>' sein. | ✓ | ✓ |
| Miko_3216 | Statische Felder mit Initialisierern sollten schreibgeschützt sein | ✓ | ✓ |
| Miko_3217 | Verwenden Sie keine generischen Typen mit anderen generischen Typen als Typargumente | ✓ | - - |
| Miko_3218 | Definieren Sie keine Erweiterungsmethoden an unerwarteten Stellen | ✓ | - - |
| Miko_3219 | Öffentliche Mitglieder sollten nicht "virtuell" sein | ✓ | - - |
| Miko_3220 | Logisch '&&' oder '||' ' Bedingungen, die "wahr" oder "False" verwenden, sollten vereinfacht werden | ✓ | ✓ |
| Miko_3221 | Gethashcode -Überschreibungen sollten 'HashCode.combine' verwenden. | ✓ | ✓ |
| Miko_3222 | String -Vergleiche können vereinfacht werden | ✓ | ✓ |
| Miko_3223 | Referenzvergleiche können vereinfacht werden | ✓ | ✓ |
| Miko_3224 | Wertvergleiche können vereinfacht werden | ✓ | ✓ |
| Miko_3225 | Redundante Vergleiche können vereinfacht werden | ✓ | ✓ |
| Miko_3301 | Bevorzugung Lambda -Expressionskörper anstelle von Klammern Lambda -Expressionsblöcken für einzelne Aussagen | ✓ | ✓ |
| Miko_3302 | Bevorzugt einfache Lambda -Expressionskörper anstelle von Klammern Lambda -Expressionskörpern für einzelne Parameter | ✓ | ✓ |
| Miko_3401 | Namespace -Hierarchien sollten nicht zu tief sein | ✓ | - - |
| Miko_3501 | Unterdrücken Sie keine nullbaren Warnungen für Null-Conditional-Operatoren | ✓ | ✓ |
| Miko_3502 | Unterdrücken Sie keine nullbaren Warnungen bei LINQ -Anrufen | ✓ | ✓ |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_4001 | Methoden mit demselben Namen sollten basierend auf der Anzahl ihrer Parameter bestellt werden | ✓ | ✓ |
| Miko_4002 | Methoden mit gleichem Namen und Zugänglichkeit sollten nebeneinander platziert werden | ✓ | ✓ |
| Miko_4003 | Entsorgen Sie Methoden sollten direkt nach Konstruktoren und Finalizern platziert werden | ✓ | ✓ |
| Miko_4004 | Entsorgen Sie Methoden sollten vor allen anderen Methoden derselben Zugänglichkeit platziert werden | ✓ | ✓ |
| Miko_4005 | Die Schnittstelle, die einen Typ angibt, sollte direkt nach der Deklaration des Typs platziert werden | ✓ | ✓ |
| Miko_4007 | Bediener sollten vor Methoden platziert werden | ✓ | ✓ |
| Miko_4008 | Gethashcode -Methoden sollten direkt nach Equals -Methoden platziert werden | ✓ | ✓ |
| Miko_4101 | Testinitialisierungsmethoden sollten direkt nach einmaligen Methoden bestellt werden | ✓ | ✓ |
| Miko_4102 | Testbereinigungsmethoden sollten nach Testinitialisierungsmethoden und vor Testmethoden bestellt werden | ✓ | ✓ |
| Miko_4103 | Einmalige Testinitialisierungsmethoden sollten vor allen anderen Methoden bestellt werden | ✓ | ✓ |
| Miko_4104 | Einmalige Testbereinigungsmethoden sollten direkt nach einmaligen Testinitialisierungsmethoden bestellt werden | ✓ | ✓ |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_5001 | "Debug" und "Debugformat" -Methoden sollten erst nach "isdebugenabled" aufgerufen werden | ✓ | ✓ |
| Miko_5002 | "XXXXFormat" -Methoden sollten nur mit mehreren Argumenten aufgerufen werden | ✓ | ✓ |
| Miko_5003 | Richtige Protokollmethoden sollten für Ausnahmen aufgerufen werden | ✓ | - - |
| Miko_5010 | Verwenden Sie nicht 'Object.equals ()' bei Werttypen | ✓ | ✓ |
| Miko_5011 | Verkettieren Sie keine Saiten mit += Operator | ✓ | - - |
| Miko_5012 | Verwenden Sie nicht "Ertragsrendite" für rekursiv definierte Strukturen | ✓ | - - |
| Miko_5013 | Erstellen Sie keine leeren Arrays | ✓ | ✓ |
| Miko_5014 | Erstellen Sie keine leeren Listen, wenn der Rückgabewert schreibgeschützt ist | ✓ | ✓ |
| Miko_5015 | Praktizieren Sie keine String -Literale | ✓ | ✓ |
| Miko_5016 | Verwenden Sie einen Hashset für Such -Such -In 'list.removeall' ' | ✓ | - - |
| Miko_5017 | Felder oder Variablen, die mit String -Literalen zugewiesen sind, sollten konstant sein | ✓ | ✓ |
| AUSWEIS | Titel | Standardmäßig aktiviert | CodeFix verfügbar |
|---|---|---|---|
| Miko_6001 | Protokollanweisungen sollten von leeren Zeilen umgeben sein | ✓ | ✓ |
| Miko_6002 | Assertion -Aussagen sollten von leeren Linien umgeben sein | ✓ | ✓ |
| Miko_6003 | Lokale variable Anweisungen sollten leere Zeilen vorausgehen | ✓ | ✓ |
| 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 | ArgumentOutOfRangeException.ThrowIf statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6024 | 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 when fitting | ✓ | ✓ |
| MiKo_6044 | 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 | ✓ | ✓ |
| MiKo_6053 | Single-line arguments shall be placed on single line | ✓ | ✓ |
| MiKo_6054 | Lambda arrows shall be placed on same line as the parameter(s) of the lambda | ✓ | ✓ |
| MiKo_6055 | Assignment statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6056 | Brackets of collection expressions should be placed directly at the same place collection initializer braces would be positioned | ✓ | ✓ |
| MiKo_6057 | Type parameter constraint clauses should be aligned vertically | ✓ | ✓ |
| MiKo_6058 | Type parameter constraint clauses should be indented below parameter list | ✓ | ✓ |
| MiKo_6059 | Multi-line conditions are positioned outdented below associated calls | ✓ | ✓ |
| MiKo_6060 | Switch case labels should be placed on same line | ✓ | ✓ |
| MiKo_6061 | Switch expression arms should be placed on same line | ✓ | ✓ |
| MiKo_6070 | Console statements should be surrounded by blank lines | ✓ | ✓ |
| MiKo_6071 | Local using statements should be surrounded by blank lines | ✓ | ✓ |
