MiKo Analyzers
1.0.0
Fournit des analyseurs basés sur la plate-forme de compilateur .NET (Roslyn) et peut être utilisé dans Visual Studio 2019 (V16.11) ou 2022 (V17.11).
Comment installer un analyseur Roslyn est décrit ici.
Des captures d'écran sur la façon d'utiliser de tels analyseurs peuvent être trouvées ici.
Les tableaux suivants répertorient toutes les 473 règles actuellement fournies par l'analyseur.
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_0001 | La méthode est trop grande | ✓ | - |
| Miko_0002 | La méthode est trop complexe | ✓ | - |
| Miko_0003 | Le type est trop grand | ✓ | - |
| Miko_0004 | La méthode a trop de paramètres | ✓ | - |
| Miko_0005 | La fonction locale est trop grande | ✓ | - |
| Miko_0006 | La fonction locale est trop complexe | ✓ | - |
| Miko_0007 | La fonction locale a trop de paramètres | ✓ | - |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_1000 | Les types de 'System.Eventargs devraient être suffixés avec des' EventArgs ' | ✓ | ✓ |
| Miko_1001 | Les paramètres de «System.Eventargs doivent être nommés« e » | ✓ | ✓ |
| Miko_1002 | Les paramètres doivent être nommés selon les directives de conception .NET Framework pour les gestionnaires d'événements | ✓ | ✓ |
| Miko_1003 | Les noms de méthode de traitement des événements doivent suivre les directives de conception .NET Framework | ✓ | ✓ |
| Miko_1004 | Les événements ne doivent pas contenir un terme «événement» dans leur nom | ✓ | ✓ |
| Miko_1005 | Les variables «System.Eventargs doivent être nommées correctement | ✓ | ✓ |
| Miko_1006 | Les événements doivent utiliser 'EventHandler <T>' avec 'EventArgs' qui portent le nom de l'événement | ✓ | - |
| Miko_1007 | Les événements et leurs types «Eventargs» correspondants doivent être situés dans le même espace de noms | ✓ | - |
| Miko_1008 | Les paramètres doivent être nommés selon les directives de conception .NET Framework pour les gestionnaires d'événements de dépendance | ✓ | ✓ |
| Miko_1009 | Les variables «System.EventHandler» doivent être nommées correctement | ✓ | ✓ |
| Miko_1010 | Les méthodes ne doivent pas contenir «Canexute» ou «exécuter» dans leurs noms | ✓ | ✓ |
| Miko_1011 | Les méthodes ne doivent pas contenir de «faire» dans leurs noms | ✓ | ✓ |
| Miko_1012 | Les méthodes doivent être nommées «augmenter» au lieu de «feu» | ✓ | ✓ |
| Miko_1013 | Les méthodes ne doivent pas être nommées «notifier» ou «onnotify» | ✓ | ✓ |
| Miko_1014 | Les méthodes ne doivent pas être nommées avec un «chèque» ambigu | ✓ | ✓ |
| Miko_1015 | Les méthodes doivent être nommées «initialiser» au lieu de «init» | ✓ | ✓ |
| Miko_1016 | Les méthodes d'usine doivent être nommées «créer» | ✓ | ✓ |
| Miko_1017 | Les méthodes ne doivent pas être préfixées par «get» ou «set» si elles sont suivies de «IS», «Can» ou «Has» | ✓ | ✓ |
| Miko_1018 | Les méthodes ne doivent pas être suffixées avec le nom d'un verbe | ✓ | ✓ |
| Miko_1019 | Les méthodes «claires» et «supprimer» doivent être nommées en fonction de leur nombre de paramètres | ✓ | ✓ |
| Miko_1020 | Les noms de type doivent être limités en longueur | - | - |
| Miko_1021 | Les noms de méthode doivent être limités en longueur | - | - |
| Miko_1022 | Les noms de paramètres doivent être limités en longueur | - | - |
| Miko_1023 | Les noms de champ doivent être limités en longueur | - | - |
| Miko_1024 | Les noms de propriété doivent être limités en longueur | - | - |
| Miko_1025 | Les noms d'événements doivent être limités en longueur | - | - |
| Miko_1026 | Les noms variables doivent être limités en longueur | - | - |
| Miko_1027 | Les noms variables en boucles doivent être limités en longueur | - | - |
| Miko_1028 | Les noms de fonction locaux doivent être limités en longueur | - | - |
| Miko_1030 | Les types ne doivent pas avoir un marqueur «abstrait» ou «base» pour indiquer que ce sont des types de base | ✓ | ✓ |
| Miko_1031 | Les types d'entités ne doivent pas utiliser un suffixe de «modèle» | ✓ | ✓ |
| Miko_1032 | Les méthodes traitant des entités ne devraient pas utiliser un «modèle» comme marqueur | ✓ | ✓ |
| Miko_1033 | Les paramètres représentant les entités ne doivent pas utiliser un suffixe de «modèle» | ✓ | ✓ |
| Miko_1034 | Les champs représentant les entités ne devraient pas utiliser de suffixe de «modèle» | ✓ | ✓ |
| Miko_1035 | Les propriétés traitant des entités ne doivent pas utiliser de marqueur «modèle» | ✓ | ✓ |
| Miko_1036 | Les événements traitant des entités ne devraient pas utiliser de marqueur «modèle» | ✓ | ✓ |
| Miko_1037 | Les types ne doivent pas être suffixés avec «type», «interface», «classe», «structure», «enregistrement» ou «enum» | ✓ | ✓ |
| Miko_1038 | Les classes contenant des méthodes d'extension devraient se terminer avec le même suffixe | ✓ | ✓ |
| Miko_1039 | Le paramètre «ce» paramètre de l'extension devrait avoir un nom par défaut | ✓ | ✓ |
| Miko_1040 | Les paramètres ne doivent pas être suffixés avec les détails de l'implémentation | ✓ | - |
| Miko_1041 | Les champs ne doivent pas être suffixés avec les détails de l'implémentation | ✓ | - |
| Miko_1042 | Les paramètres «d'annulation» devraient avoir un nom spécifique | ✓ | ✓ |
| Miko_1043 | Les variables «d'annulation» devraient avoir un nom spécifique | ✓ | ✓ |
| Miko_1044 | Les commandes doivent être suffixées avec 'Command' | ✓ | ✓ |
| Miko_1045 | Les méthodes invoquées par les commandes ne doivent pas être suffixées avec «Commande» | ✓ | ✓ |
| Miko_1046 | Les méthodes asynchrones devraient suivre le modèle asynchrone basé sur les tâches (TAP) | ✓ | ✓ |
| Miko_1047 | Les méthodes qui ne suivent pas le modèle asynchrone basé sur les tâches (TAP) ne doivent pas mentir sur le fait d'être asynchrone | ✓ | ✓ |
| Miko_1048 | Les classes qui sont des convertisseurs de valeur devraient se terminer par un suffixe spécifique | ✓ | ✓ |
| Miko_1049 | N'utilisez pas de conditions d'exigence telles que «doit», «devrait», «doit» ou «besoin» pour les noms | ✓ | ✓ |
| Miko_1050 | Les valeurs de retour devraient avoir des noms descriptifs | ✓ | ✓ |
| Miko_1051 | Ne suffisez pas les paramètres avec des types de délégués | ✓ | ✓ |
| Miko_1052 | Ne suffisez pas de variables avec des types de délégués | ✓ | ✓ |
| Miko_1053 | Ne suffix pas les champs avec des types de délégués | ✓ | ✓ |
| Miko_1054 | Ne nommez pas les types «aide» ou «utilitaire» | ✓ | ✓ |
| Miko_1055 | Les propriétés de dépendance doivent être suffixées avec «propriété» (comme dans le framework .NET) | ✓ | ✓ |
| Miko_1056 | Les propriétés de dépendance doivent être préfixées avec des noms de propriétés (comme dans le framework .NET) | ✓ | ✓ |
| Miko_1057 | Les clés de propriété de dépendance doivent être suffixées avec une «clé» (comme dans le framework .net) | ✓ | ✓ |
| Miko_1058 | Les clés de propriété de dépendance doivent être préfixées avec des noms de propriétés (comme dans le framework .NET) | ✓ | ✓ |
| Miko_1059 | Ne nommez pas les types «impl» ou «implémentation» | ✓ | ✓ |
| Miko_1060 | Utilisez '<entity> notfound' au lieu de 'Get <entity> a échoué' ou '<entity> manquant' | ✓ | ✓ |
| Miko_1061 | Le nom du paramètre de la méthode «Essayer» doit être spécifique | ✓ | ✓ |
| Miko_1062 | Les méthodes, les propriétés ou les champs «peuvent / contenu / contenu» ne doit être composé que de quelques mots | ✓ | - |
| Miko_1063 | N'utilisez pas les abréviations en noms | ✓ | ✓ |
| Miko_1064 | Les noms de paramètres reflètent leur signification et non leur type | ✓ | - |
| Miko_1065 | Les paramètres de l'opérateur doivent être nommés selon les directives de conception .NET Framework pour les surcharges de l'opérateur | ✓ | ✓ |
| Miko_1066 | Les paramètres du constructeur affectés à une propriété doivent être nommés d'après la propriété | ✓ | ✓ |
| Miko_1067 | Les méthodes ne doivent pas contenir de «performance» dans leurs noms | ✓ | ✓ |
| Miko_1068 | Les méthodes de workflow doivent être nommées «Canrun» ou «Run» | ✓ | - |
| Miko_1069 | Les noms de propriété reflètent leur signification et non leur type | ✓ | - |
| Miko_1070 | Les variables de collecte locales doivent utiliser le nom pluriel | ✓ | ✓ |
| Miko_1071 | Les variables booléennes locales doivent être nommées énoncés et non comme des questions | ✓ | - |
| Miko_1072 | Les propriétés ou méthodes booléennes doivent être nommées comme des déclarations et non comme des questions | ✓ | - |
| Miko_1073 | Les champs booléens doivent être nommés comme des déclarations et non comme des questions | ✓ | - |
| Miko_1074 | Les objets utilisés pour verrouiller doivent être suffixés avec «verrouillage» | ✓ | - |
| Miko_1075 | Les types de non-système.eventargs ne doivent pas être suffixés avec des `` Eventargs '' | ✓ | ✓ |
| Miko_1076 | Les types d'événements PRISM doivent être suffixés avec un «événement» | ✓ | ✓ |
| Miko_1077 | Les membres de l'énumération ne doivent pas être suffixés avec 'Enum' | ✓ | ✓ |
| Miko_1078 | Les noms de méthode du générateur doivent commencer par «build» | ✓ | ✓ |
| Miko_1079 | Les référentiels ne doivent pas être suffixés avec le «référentiel» | ✓ | ✓ |
| Miko_1080 | Les noms doivent contenir des nombres au lieu de leur orthographe | ✓ | - |
| Miko_1081 | Les méthodes ne doivent pas être suffixées avec un numéro | ✓ | ✓ |
| Miko_1082 | Les propriétés ne doivent pas être suffixées avec un nombre si leurs types ont des suffixes numériques | ✓ | ✓ |
| Miko_1083 | Les champs ne doivent pas être suffixés avec un nombre si leurs types ont des suffixes numériques | ✓ | ✓ |
| Miko_1084 | Les variables ne doivent pas être suffixées avec un nombre si leurs types ont des suffixes de nombres | ✓ | ✓ |
| Miko_1085 | Les paramètres ne doivent pas être suffixés avec un nombre | ✓ | ✓ |
| Miko_1086 | Les méthodes ne doivent pas être nommées en utilisant des nombres comme argot | ✓ | - |
| Miko_1087 | Nom des paramètres du constructeur après leurs homologues dans la classe de base | ✓ | ✓ |
| Miko_1088 | Les instances de singleton doivent être nommées «instance» | ✓ | - |
| Miko_1089 | Les méthodes ne doivent pas être préfixées par «get» | ✓ | ✓ |
| Miko_1090 | Les paramètres ne doivent pas être suffixés avec des types spécifiques | ✓ | ✓ |
| Miko_1091 | Les variables ne doivent pas être suffixées avec des types spécifiques | ✓ | ✓ |
| Miko_1092 | Les types de «capacité» ne doivent pas être suffixés avec des informations redondantes | ✓ | ✓ |
| Miko_1093 | N'utilisez pas le suffixe «objet» ou «structure» | ✓ | ✓ |
| Miko_1094 | Ne suffix pas les types avec des noms d'espace de noms passifs | ✓ | - |
| Miko_1095 | N'utilisez pas «supprimer» et «supprimer» à la fois dans les noms et la documentation | ✓ | - |
| Miko_1096 | Les noms doivent utiliser «échoué» au lieu de «notant» | ✓ | - |
| Miko_1097 | Les noms de paramètres ne doivent pas suivre le schéma de dénomination des champs | ✓ | ✓ |
| Miko_1098 | Les noms de type doivent refléter la ou les interfactions commerciales qu'ils implémentent | ✓ | - |
| Miko_1099 | Les paramètres correspondants sur les surcharges de méthode devraient avoir des noms identiques | ✓ | ✓ |
| Miko_1100 | Les classes de test doivent commencer par le nom du type testé | ✓ | - |
| Miko_1101 | Les classes de test devraient se terminer par des «tests» | ✓ | ✓ |
| Miko_1102 | Les méthodes de test ne doivent pas contenir de «test» dans leurs noms | ✓ | ✓ |
| Miko_1103 | Les méthodes d'initialisation des tests doivent être nommées «préparatoires» | ✓ | ✓ |
| Miko_1104 | Les méthodes de nettoyage de test doivent être nommées «Cleanuptest» | ✓ | ✓ |
| Miko_1105 | Les méthodes d'initialisation de test unique doivent être nommées «préparation de l'environnement» | ✓ | ✓ |
| Miko_1106 | Les méthodes de nettoyage de test unique doivent être nommées «Cleanuptetensivironment» | ✓ | ✓ |
| Miko_1107 | Les méthodes de test ne doivent pas être en cas de cascal | ✓ | ✓ |
| Miko_1108 | Ne nommez pas les variables, les paramètres, les champs et les propriétés «Mock», «Stub», «Fake» ou «SHIM» | ✓ | ✓ |
| Miko_1109 | Préfixes Types testables avec «testable» au lieu d'utiliser le suffixe «UT» | ✓ | ✓ |
| Miko_1110 | Les méthodes de test avec les paramètres doivent être suffixées avec un soulignement | ✓ | ✓ |
| Miko_1111 | Les méthodes de test sans paramètres ne doivent pas être suffixées avec un soulignement | ✓ | ✓ |
| Miko_1112 | Ne nommez pas les données de test «arbitraires» | ✓ | ✓ |
| Miko_1113 | Les méthodes de test ne doivent pas être nommées selon le style BDD | ✓ | - |
| Miko_1114 | Les méthodes de test ne doivent pas être nommées «Happypath» ou «badpath» | ✓ | - |
| Miko_1115 | Les méthodes de test doivent être nommées de manière courante | ✓ | ✓ |
| Miko_1200 | Nom Exceptions dans les blocs de capture cohérentes | ✓ | ✓ |
| Miko_1201 | Nom des exceptions en tant que paramètres de manière cohérente | ✓ | ✓ |
| Miko_1300 | Les identifiants sans importance dans les déclarations de lambda doivent être nommés '_' | ✓ | ✓ |
| Miko_1400 | Les noms de l'espace de noms devraient être au pluriel | ✓ | - |
| Miko_1401 | Les espaces de noms ne doivent pas contenir de noms de langue technique | ✓ | - |
| Miko_1402 | Les espaces de noms ne doivent pas être nommés d'après les modèles de conception spécifiques au WPF | ✓ | - |
| Miko_1403 | Les espaces de noms ne doivent être nommés d'après aucun de leurs espaces de noms parents | ✓ | - |
| Miko_1404 | Les espaces de noms ne doivent pas contenir de noms non spécifiques | ✓ | - |
| Miko_1405 | Les espaces de noms ne doivent pas contenir de «lib» | ✓ | - |
| Miko_1406 | Les convertisseurs de valeur doivent être placés dans l'espace de noms «convertisseurs» | ✓ | - |
| Miko_1407 | Les espaces de noms de test ne doivent pas contenir de «test» | ✓ | - |
| Miko_1408 | Les méthodes d'extension doivent être placées dans le même espace de noms que les types étendus | ✓ | - |
| Miko_1409 | Ne préfixez pas ou ne suffix pas sur des espaces de noms avec des traits | ✓ | - |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_2000 | La documentation doit être valide XML | ✓ | ✓ |
| Miko_2001 | Les événements doivent être documentés correctement | ✓ | ✓ |
| Miko_2002 | EventArgs doit être documenté correctement | ✓ | ✓ |
| Miko_2003 | La documentation des gestionnaires d'événements devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2004 | La documentation des noms de paramètres du gestionnaire d'événements doit suivre les directives de conception du framework .NET pour les gestionnaires d'événements | ✓ | ✓ |
| Miko_2005 | Les références textuelles à EventArgs doivent être documentées correctement | ✓ | - |
| Miko_2006 | Les événements routés doivent être documentés comme le fait par le framework .NET | ✓ | ✓ |
| Miko_2010 | Les classes scellées devraient documenter en être scellé | ✓ | ✓ |
| Miko_2011 | Les classes non scellées ne devraient pas mentir sur la scelle | ✓ | ✓ |
| Miko_2012 | <Summary> La documentation devrait décrire la responsabilité du type | ✓ | ✓ |
| Miko_2013 | <Summary> La documentation des énumations devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2014 | Les méthodes disposées doivent être documentées comme le fait par le framework .NET | ✓ | ✓ |
| Miko_2015 | La documentation doit utiliser «augmenter» ou «lancer» au lieu de «feu» | ✓ | ✓ |
| Miko_2016 | La documentation des méthodes asynchrones devrait commencer par une phrase spécifique | ✓ | ✓ |
| Miko_2017 | Les propriétés de dépendance doivent être documentées comme le fait par le .NET Framework | ✓ | ✓ |
| Miko_2018 | La documentation ne doit pas utiliser les termes ambigus «vérifier» ou «test» | ✓ | ✓ |
| Miko_2019 | <Summary> La documentation devrait commencer par un verbe singulier à la troisième personne (par exemple "fournit") | ✓ | - |
| Miko_2020 | La documentation héréditaire doit être utilisée avec <hheritdoc /> marqueur | ✓ | ✓ |
| Miko_2021 | La documentation du paramètre devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2022 | La documentation des paramètres [Out] devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2023 | La documentation des paramètres booléens devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2024 | La documentation des paramètres d'énumération devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2025 | La documentation des paramètres «Annulation» devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2026 | Les paramètres utilisés ne doivent pas être documentés pour être inutilisés | ✓ | - |
| Miko_2027 | Les paramètres du constructeur de sérialisation doivent être documentés avec une phrase spécifique | ✓ | ✓ |
| Miko_2028 | La documentation du paramètre ne doit pas seulement contenir le nom du paramètre | ✓ | - |
| Miko_2029 | <NheritDoc> La documentation ne doit pas utiliser un «Cref» pour lui-même | ✓ | ✓ |
| Miko_2030 | La documentation de la valeur de retour devrait avoir une phrase de départ par défaut | ✓ | - |
| Miko_2031 | La documentation de la valeur de retour des tâches devrait avoir une phrase spécifique (de départ) | ✓ | ✓ |
| Miko_2032 | La documentation de la valeur de retour booléenne devrait avoir une phrase spécifique | ✓ | ✓ |
| Miko_2033 | La documentation de la valeur de retour de chaîne devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2034 | La documentation de la valeur de rendement de l'énumération devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2035 | La documentation de la valeur de retour de la collection devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2036 | La documentation de la propriété booléenne ou énumérée doit décrire la valeur par défaut | ✓ | ✓ |
| Miko_2037 | <Summary> La documentation des propriétés de commande devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2038 | <Summary> La documentation de la commande devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2039 | <Summary> La documentation des classes contenant des méthodes d'extension devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2040 | <voir langword = "..." /> doit être utilisé à la place <c> ... </c> | ✓ | ✓ |
| Miko_2041 | <Summary> La documentation ne doit pas contenir d'autres balises de documentation | ✓ | ✓ |
| Miko_2042 | La documentation doit utiliser les balises '<para />' xml au lieu de tags '<br/>' html | ✓ | ✓ |
| Miko_2043 | <Summary> La documentation des délégués personnalisées devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2044 | Documentation références à la méthode Paramètres correctement | ✓ | ✓ |
| Miko_2045 | <Summary> La documentation ne doit pas référencer les paramètres | ✓ | ✓ |
| Miko_2046 | La documentation doit référencer correctement les paramètres du type | ✓ | ✓ |
| Miko_2047 | <Summary> La documentation des attributs devrait avoir une phrase de départ par défaut | ✓ | - |
| Miko_2048 | <Summary> La documentation des convertisseurs de valeur devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2049 | La documentation doit être plus explicite et ne pas utiliser «sera» | ✓ | ✓ |
| Miko_2050 | Les exceptions doivent être documentées après le framework .NET | ✓ | ✓ |
| Miko_2051 | Les exceptions lancées doivent être documentées comme une sorte de condition (comme '<paramref name = "xyz" /> est <c> 42 </c>') | ✓ | ✓ |
| Miko_2052 | Le lancement d'argument de la nulxception doit être documenté en utilisant une phrase par défaut | ✓ | ✓ |
| Miko_2053 | Le lancement d'argument Nullexception ne doit être documenté que pour les paramètres de type de référence | ✓ | - |
| Miko_2054 | Le lancement de ArgumentException doit être documenté en utilisant une phrase de départ par défaut | ✓ | ✓ |
| Miko_2055 | Le lancement d'argumentoutofRangeException doit être documenté à l'aide d'une phrase de départ par défaut | ✓ | ✓ |
| Miko_2056 | Le lancer de ObjectDisposedException doit être documenté à l'aide d'une phrase de fin par défaut | ✓ | ✓ |
| Miko_2057 | Les types qui ne sont pas jetables ne doivent pas lancer une exception d'objectif | ✓ | ✓ |
| Miko_2059 | La documentation multiple de la même exception doit être consolidée en une | ✓ | ✓ |
| Miko_2060 | Les usines doivent être documentées de manière uniforme | ✓ | ✓ |
| Miko_2070 | <Summary> La documentation ne doit pas commencer par «retourne» | ✓ | ✓ |
| Miko_2071 | <Summary> Documentation pour les méthodes qui renvoient les types d'énumération ne doivent pas contenir une phrase pour le type booléen | ✓ | - |
| Miko_2072 | <Summary> La documentation ne doit pas commencer par «essayer» | ✓ | ✓ |
| Miko_2073 | <Summary> La documentation des méthodes «contient» devrait commencer par «déterminer si» | ✓ | ✓ |
| Miko_2074 | La documentation du paramètre de la méthode «contient» devrait avoir une phrase de fin par défaut | ✓ | ✓ |
| Miko_2075 | La documentation doit utiliser le terme «rappel» au lieu de «action», «func» ou «fonction» | ✓ | ✓ |
| Miko_2076 | La documentation doit documenter les valeurs par défaut des paramètres facultatifs | ✓ | ✓ |
| Miko_2077 | <Summary> La documentation ne doit pas contenir <code> | ✓ | - |
| Miko_2078 | <code> La documentation ne doit pas contenir de balises XML | ✓ | - |
| Miko_2079 | <Summary> La documentation des propriétés ne doit pas avoir de texte évident | ✓ | ✓ |
| Miko_2080 | <Summary> La documentation des champs devrait avoir une phrase de départ par défaut | ✓ | ✓ |
| Miko_2081 | <Summary> La documentation des champs en lecture uniquement visibles devrait avoir une phrase de fin par défaut | ✓ | ✓ |
| Miko_2082 | <Summary> La documentation des membres de l'énum ne doit pas commencer par les phrases de démarrage par défaut de l'énumération <s résumé> documentation | ✓ | ✓ |
| Miko_2090 | La documentation de l'opérateur d'égalité doit avoir une phrase par défaut | ✓ | ✓ |
| Miko_2091 | La documentation de l'opérateur d'inégalité doit avoir une phrase par défaut | ✓ | ✓ |
| Miko_2100 | <exemple> La documentation doit commencer par une phrase par défaut descriptive | ✓ | ✓ |
| Miko_2101 | <exemple> La documentation doit afficher un exemple de code dans les balises <code> | ✓ | ✓ |
| Miko_2200 | Utilisez une lettre capitalisée pour démarrer le commentaire | ✓ | ✓ |
| Miko_2201 | Utilisez une lettre capitalisée pour démarrer les phrases dans le commentaire | ✓ | - |
| Miko_2202 | La documentation doit utiliser le terme «identifiant» au lieu de «ID» | ✓ | ✓ |
| Miko_2203 | La documentation doit utiliser le terme «identifiant unique» au lieu de «GUID» | ✓ | ✓ |
| Miko_2204 | La documentation doit utiliser <Sist> pour les énumérations | ✓ | ✓ |
| Miko_2205 | La documentation doit utiliser <Remarque> pour des informations importantes | ✓ | - |
| Miko_2206 | La documentation ne doit pas utiliser le terme «drapeau» | ✓ | - |
| Miko_2207 | <Summary> La documentation doit être courte | ✓ | - |
| Miko_2208 | La documentation ne doit pas utiliser le terme «une instance de» | ✓ | ✓ |
| Miko_2209 | N'utilisez pas de deux périodes dans la documentation | ✓ | ✓ |
| Miko_2210 | La documentation doit utiliser le terme «information» au lieu de «info» | ✓ | ✓ |
| Miko_2211 | Les membres de l'énumération ne devraient pas avoir de sections <Remarques> | ✓ | ✓ |
| Miko_2212 | La documentation doit utiliser l'expression «échoué» au lieu de «n'a pas réussi» | ✓ | ✓ |
| Miko_2213 | La documentation ne doit pas utiliser la contraction "n'est pas" | ✓ | ✓ |
| Miko_2214 | La documentation ne doit pas contenir de lignes vides | ✓ | ✓ |
| Miko_2215 | Les phrases en documentation doivent être courtes | ✓ | - |
| Miko_2216 | Utilisez <Ar paramref> au lieu de <param> pour référence aux paramètres | ✓ | ✓ |
| Miko_2217 | <swist> La documentation est effectuée correctement | ✓ | ✓ |
| Miko_2218 | La documentation doit utiliser des termes plus courts au lieu d'un terme plus long «utilisé pour / dans / par» | ✓ | ✓ |
| Miko_2219 | N'utilisez pas de marques de question ou d'explication dans la documentation | ✓ | - |
| Miko_2220 | La documentation doit utiliser «chercher» au lieu de «chercher», «pour inspecter« ou «tester» | ✓ | ✓ |
| Miko_2221 | La documentation ne doit pas utiliser les balises XML vides | ✓ | - |
| Miko_2222 | La documentation doit utiliser le terme «identification» au lieu de «identifier» | ✓ | ✓ |
| Miko_2223 | Les références de documentation des références via <voir cref = "..." /> | ✓ | - |
| Miko_2224 | La documentation doit avoir des balises XML et des textes placés sur des lignes séparées | ✓ | ✓ |
| Miko_2225 | Le code marqué avec des balises <c> doit être placé sur une seule ligne | ✓ | ✓ |
| Miko_2226 | La documentation devrait expliquer le «pourquoi» et non le «cela» | ✓ | - |
| Miko_2227 | La documentation ne doit pas contenir de suppressions de resharper | ✓ | - |
| Miko_2228 | La documentation doit utiliser un libellé positif au lieu de négatif | ✓ | - |
| Miko_2229 | La documentation ne doit pas contenir des fragments XML restants | ✓ | ✓ |
| Miko_2231 | La documentation des méthodes remplacées 'GethashCode ()' doit utiliser '<hheRitdoc />' marqueur | ✓ | ✓ |
| Miko_2232 | <Summary> La documentation ne doit pas être vide | ✓ | ✓ |
| Miko_2233 | Les balises XML doivent être placées sur une seule ligne | ✓ | ✓ |
| Miko_2300 | Les commentaires devraient expliquer le «pourquoi» et non le «comment» | ✓ | - |
| Miko_2301 | N'utilisez pas de commentaires évidents dans les tests AAA | ✓ | ✓ |
| Miko_2302 | Ne gardez pas le code qui est commenté | ✓ | - |
| Miko_2303 | Ne terminez pas les commentaires avec une période | ✓ | ✓ |
| Miko_2304 | Ne formulez pas les commentaires comme des questions | ✓ | - |
| Miko_2305 | N'utilisez pas de deux périodes dans les commentaires | ✓ | ✓ |
| Miko_2306 | Terminer les commentaires avec une période | - | - |
| Miko_2307 | Les commentaires devraient utiliser l'expression «échoué» au lieu de «n'a pas réussi» | ✓ | ✓ |
| Miko_2308 | Ne placez pas de commentaires sur une seule ligne avant de fermer l'attelle mais après le code | ✓ | ✓ |
| Miko_2309 | Les commentaires ne devraient pas utiliser la contraction "n'est pas" | ✓ | ✓ |
| Miko_2310 | Les commentaires devraient expliquer le «pourquoi» et non le «cela» | ✓ | - |
| Miko_2311 | N'utilisez pas les commentaires du séparateur | ✓ | ✓ |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_3000 | N'utilisez pas les régions vides | ✓ | - |
| Miko_3001 | Les délégués personnalisés ne doivent pas être utilisés | ✓ | - |
| Miko_3002 | Les classes ne devraient pas avoir trop de dépendances | ✓ | - |
| Miko_3003 | Les événements doivent suivre les directives de conception .NET Framework pour les événements | ✓ | - |
| Miko_3004 | Les réglages de propriétés de EventArgs seront privés | ✓ | - |
| Miko_3005 | Les méthodes nommées «Try» doivent suivre le trier-doer-sattern | ✓ | - |
| Miko_3006 | Le paramètre «d'annulation» devrait être le dernier paramètre de méthode | ✓ | - |
| Miko_3007 | N'utilisez pas la méthode LINQ et la syntaxe de requête déclarative dans la même méthode | ✓ | - |
| Miko_3008 | La méthode ne doit pas retourner les collections qui peuvent être modifiées de l'extérieur | ✓ | - |
| Miko_3009 | Les commandes doivent invoquer uniquement les méthodes nommées et aucune expression de lambda | ✓ | - |
| Miko_3010 | Ne créez pas et ne jetez pas les types d'exceptions réservées | ✓ | - |
| Miko_3011 | Les conceptions argumentaires lancées (ou ses sous-types) doivent fournir le nom du paramètre correct | ✓ | ✓ |
| Miko_3012 | L'argument Office OfRangeExceptions (ou ses sous-types) doit fournir la valeur réelle qui provoque l'exception de l'exception | ✓ | ✓ |
| Miko_3013 | La clause «par défaut» dans les instructions «Switch» devrait lancer un argumentofRangeException (ou un sous-type), mais pas d'argumentException | ✓ | ✓ |
| Miko_3014 | InvalidOperationException, NotImplementEdException et NotSupportEdException devraient avoir une raison en tant que message | ✓ | ✓ |
| Miko_3015 | Jetez des conceptions d'invalidOperation (au lieu des exceptions d'arguments ou de ses sous-types) pour indiquer des états inappropriés de méthodes sans paramètres | ✓ | ✓ |
| Miko_3016 | Ne jetez pas d'argument de nulxception pour les états inappropriés des valeurs de retour de propriété | ✓ | ✓ |
| Miko_3017 | N'avalez pas des exceptions lorsque vous lancez de nouvelles exceptions | ✓ | ✓ |
| Miko_3018 | Jetez des exceptions d'objets Disposed sur les méthodes visibles publiquement des types jetables | ✓ | - |
| Miko_3020 | Utilisez 'tâche.complettedtask' au lieu de 'tâche.fromresult' | ✓ | ✓ |
| Miko_3021 | N'utilisez pas «tâche.run» dans l'implémentation | ✓ | - |
| Miko_3022 | Ne renvoyez pas la tâche <IEnunuable> ou la tâche <ienumerable <T>> | ✓ | - |
| Miko_3023 | N'utilisez pas «annulationtokensource» comme paramètre | ✓ | - |
| Miko_3024 | N'utilisez pas le mot-clé [ref] sur les paramètres de référence | ✓ | - |
| Miko_3025 | Ne pas réaffecter les paramètres de la méthode | ✓ | - |
| Miko_3026 | Les paramètres inutilisés doivent être supprimés | ✓ | - |
| Miko_3027 | Les paramètres ne doivent pas être marqués pour être réservés à une utilisation future | ✓ | - |
| Miko_3028 | N'attribuez pas null aux paramètres de lambda | ✓ | - |
| Miko_3029 | Les enregistrements d'événements ne doivent pas provoquer de fuites de mémoire | ✓ | - |
| Miko_3030 | Les méthodes doivent suivre la loi de Demeter | - | - |
| Miko_3031 | Iclonable.clone () ne doit pas être implémenté | ✓ | - |
| Miko_3032 | Utilisez «Nomof» au lieu de CINCH pour les noms des propriétés pour les instances créées par «PropertyChangedEventArgs» | ✓ | ✓ |
| Miko_3033 | Utilisez «Nomof» pour les noms des propriétés pour les instances créées par «propriétéchangingEventargs» et «PropertyChangedEventargs» | ✓ | ✓ |
| Miko_3034 | L'équipement d'événements PropertyChanged doit utiliser l'attribut [Colembermembename] | ✓ | ✓ |
| Miko_3035 | N'invimez pas les méthodes «Waitone» sans délais d'expiration | ✓ | - |
| Miko_3036 | Préfèrent utiliser des méthodes d'usine «Timespan» au lieu des constructeurs | ✓ | ✓ |
| Miko_3037 | N'utilisez pas de numéros magiques pour les délais d'expiration | ✓ | - |
| Miko_3038 | N'utilisez pas les nombres magiques | ✓ | - |
| Miko_3039 | Les propriétés ne doivent pas utiliser LINQ ou le rendement | ✓ | - |
| Miko_3040 | N'utilisez pas les booléens à moins que vous ne soyez absolument sûr que vous n'aurez jamais besoin de plus de 2 valeurs | ✓ | - |
| Miko_3041 | EventArgs ne doit pas utiliser les délégués | ✓ | - |
| Miko_3042 | EventArgs ne doit pas mettre en œuvre des interfaces | ✓ | - |
| Miko_3043 | Utilisez «Nomof» pour les enregistrements d'événement WeakeventManager (DE-) | ✓ | ✓ |
| Miko_3044 | Utilisez «Nomof» pour comparer les noms de propriétés de «PropertyChangingEventargs» et «PropertyChangedEventargs» | ✓ | ✓ |
| Miko_3045 | Utilisez «Nomof» pour les inscriptions des événements EventManager | ✓ | ✓ |
| Miko_3046 | Utiliser «Nomof» pour les noms de propriétés des méthodes d'élévation des propriétés | ✓ | ✓ |
| Miko_3047 | Utiliser les attributs «nomof» pour application [contenuProperty] | ✓ | ✓ |
| Miko_3048 | ValuConverters doit avoir l'attribut [ValueConversion] appliqué | ✓ | - |
| Miko_3049 | Les membres de l'énum doivent faire appliquer l'attribut [Description] | ✓ | - |
| Miko_3050 | Les champs de dépendance à la dépendance devraient être «en lecture statique publique» | ✓ | ✓ |
| Miko_3051 | Les champs de dépendance de la dépendance doivent être correctement enregistrés | ✓ | ✓ |
| Miko_3052 | DependancePropertyKey Les champs devraient être des «lectures statiques» non publiques | ✓ | ✓ |
| Miko_3053 | DependencyPropertyKey Les champs doivent être correctement enregistrés | ✓ | - |
| Miko_3054 | Une lecture seule DependencyProperty devrait avoir un identifiant de dépôt exposé | ✓ | ✓ |
| Miko_3055 | ViewModels doit mettre en œuvre InotifyPropertyChanged | ✓ | - |
| Miko_3060 | Debug.asser out. asserser ne doit pas être utilisé | ✓ | ✓ |
| Miko_3061 | Les journalistes doivent utiliser une catégorie de journal appropriée | ✓ | - |
| Miko_3062 | Messages du journal final pour les exceptions avec un côlon | ✓ | ✓ |
| Miko_3063 | Mettre fin aux messages de journal non exceptionnels avec un point | ✓ | ✓ |
| Miko_3064 | Les messages de journal ne doivent pas utiliser la contraction "n'est pas" | ✓ | ✓ |
| Miko_3065 | Les appels de journalisation de Microsoft ne doivent pas utiliser les chaînes interpolées | ✓ | ✓ |
| Miko_3070 | Ne reviens pas null pour un ienumable | ✓ | - |
| Miko_3071 | Ne retournez pas null pour une tâche | ✓ | - |
| Miko_3072 | Les méthodes non privées ne doivent pas renvoyer 'Liste <>' ou 'Dictionary <>' | ✓ | - |
| Miko_3073 | Ne laissez pas les objets partiellement initialisés | ✓ | - |
| Miko_3074 | Ne définissez pas les paramètres «ref» ou «out» sur les constructeurs | ✓ | - |
| Miko_3075 | Les types internes et privés doivent être statiques ou scellés à moins que la dérivation d'eux ne soit requise | ✓ | ✓ |
| Miko_3076 | N'initialisez pas un membre statique avec un membre statique ci-dessous ou dans une autre partie de type | ✓ | - |
| Miko_3077 | Les propriétés qui renvoient une énumération devraient avoir une valeur par défaut | ✓ | ✓ |
| Miko_3078 | Les membres de l'énumération doivent avoir une valeur par défaut | ✓ | ✓ |
| Miko_3079 | Hresults doit être écrit en hexadécimal | ✓ | ✓ |
| Miko_3080 | Utilisez 'Switch ... Return' au lieu de 'Switch ... Break' lorsque vous attribuez des variables | ✓ | - |
| Miko_3081 | Préférer la correspondance du motif à une condition logique et non | ✓ | ✓ |
| Miko_3082 | Préférez la correspondance du modèle à une comparaison logique avec «vrai» ou «faux» | ✓ | ✓ |
| Miko_3083 | Préférer la correspondance du motif pour les contrôles nuls | ✓ | ✓ |
| Miko_3084 | Ne placez pas les constantes sur le côté gauche pour des comparaisons | ✓ | ✓ |
| Miko_3085 | Les déclarations conditionnelles doivent être courtes | ✓ | - |
| Miko_3086 | Ne nidisez pas les déclarations conditionnelles | ✓ | - |
| Miko_3087 | N'utilisez pas de conditions complexes négatives | ✓ | - |
| Miko_3088 | Préférer la correspondance du modèle pour les contrôles non nulles | ✓ | ✓ |
| Miko_3089 | N'utilisez pas de modèles de propriété constante simples comme conditions des instructions «si» | ✓ | ✓ |
| Miko_3090 | Ne jetez pas les exceptions dans les blocs enfin | ✓ | - |
| Miko_3091 | Ne soulevez pas d'événements dans les blocs enfin | ✓ | - |
| Miko_3092 | Ne soulevez pas d'événements dans les verrous | ✓ | - |
| Miko_3093 | N'invoquez pas les délégués à l'intérieur des serrures | ✓ | - |
| Miko_3094 | N'involez pas les méthodes ou les propriétés des paramètres à l'intérieur des verrous | ✓ | - |
| Miko_3095 | Les blocs de code ne doivent pas être vides | ✓ | - |
| Miko_3096 | Utilisez des dictionnaires au lieu de grandes instructions de commutation | ✓ | - |
| Miko_3097 | Ne pas lancer pour taper et retourner l'objet | ✓ | - |
| Miko_3098 | Les justifications des messages supprimés doivent expliquer | ✓ | - |
| Miko_3099 | Ne comparez pas les valeurs d'énumération avec null | ✓ | ✓ |
| Miko_3100 | Les classes de test et les types testées appartiennent à la même espace de noms | ✓ | - |
| Miko_3101 | Les classes de test doivent contenir des tests | ✓ | - |
| Miko_3102 | Les méthodes de test ne doivent pas contenir de déclarations conditionnelles (telles que «si», «commutateur», etc.) | ✓ | - |
| Miko_3103 | Les méthodes de test ne doivent pas utiliser «Guid.newGuid ()» | ✓ | ✓ |
| Miko_3104 | Utilisez correctement l'attribut [combinatoire] de Nunit | ✓ | ✓ |
| Miko_3105 | Les méthodes de test doivent utiliser l'approche Assert Fluent de Nunit | ✓ | ✓ |
| Miko_3106 | Les affirmations ne doivent pas utiliser les opérateurs d'égalité ou de comparaison | ✓ | - |
| Miko_3107 | MOQ MOCK CONDITION Les matchs doivent être utilisés sur des simulations uniquement | ✓ | ✓ |
| Miko_3108 | Les méthodes de test doivent utiliser des affirmations | ✓ | - |
| Miko_3109 | Les affirmations multiples utiliseront des messages d'assertion | ✓ | ✓ |
| Miko_3110 | Les affirmations ne doivent pas utiliser le «nombre» ou la «longueur» | ✓ | ✓ |
| Miko_3111 | Les affirmations doivent utiliser «is.zero» au lieu de «is.equalto (0)» | ✓ | ✓ |
| Miko_3112 | Les affirmations doivent utiliser «Is.empty» au lieu de «Has.count.zero» | ✓ | ✓ |
| Miko_3113 | N'utilisez pas de courants | ✓ | ✓ |
| Miko_3114 | Utilisez 'Mock.of <T> ()' au lieu de 'New Mock <T> (). Objet' | ✓ | ✓ |
| Miko_3115 | Les méthodes de test doivent contenir du code | ✓ | - |
| Miko_3116 | Les méthodes d'initialisation de test doivent contenir du code | ✓ | - |
| Miko_3117 | Les méthodes de nettoyage de test doivent contenir du code | ✓ | - |
| Miko_3118 | Les méthodes de test ne doivent pas utiliser les appels LINQ ambigus | ✓ | - |
| Miko_3119 | Les méthodes de test ne doivent pas simplement retourner la tâche terminée | ✓ | ✓ |
| Miko_3120 | MOQ MOCKS doit utiliser des valeurs au lieu de 'it.is <> (...)' Matcher de condition pour vérifier les valeurs exactes | ✓ | ✓ |
| Miko_3121 | Les tests doivent tester les implémentations concrètes et aucune interface | ✓ | - |
| Miko_3122 | Les méthodes de test ne doivent pas utiliser plus de 2 paramètres | ✓ | - |
| Miko_3201 | Si les déclarations peuvent être inversées dans de courtes méthodes | ✓ | ✓ |
| Miko_3202 | Utilisez des conditions positives lorsque vous retournez dans tous les chemins | ✓ | ✓ |
| Miko_3203 | Les déclarations de contenu IF peuvent être inversées lorsqu'elles sont suivies d'une seule ligne | ✓ | ✓ |
| Miko_3204 | Négatif si les déclarations peuvent être inversées lorsqu'ils ont une clause d'autre | ✓ | ✓ |
| Miko_3210 | Seules les surcharges les plus longues doivent être virtuelles ou abstraites | ✓ | - |
| Miko_3211 | Les types publics ne devraient pas avoir de finalisateurs | ✓ | - |
| Miko_3212 | Ne confondez pas les développeurs en fournissant d'autres méthodes disposées | ✓ | - |
| Miko_3213 | La méthode de disposition sans paramètres suit le modèle de disposition de base | ✓ | - |
| Miko_3214 | Les interfaces ne contiennent pas de méthodes «Begin / End» ou «Entrée / sortie» de définition de la portée | ✓ | - |
| Miko_3215 | Les rappels doivent être 'func <t, bool>' au lieu de 'Predicat <bool>' | ✓ | ✓ |
| Miko_3216 | Les champs statiques avec initialiseurs doivent être en lecture seule | ✓ | ✓ |
| Miko_3217 | N'utilisez pas de types génériques qui ont d'autres types génériques comme arguments de type | ✓ | - |
| Miko_3218 | Ne définissez pas les méthodes d'extension dans des endroits inattendus | ✓ | - |
| Miko_3219 | Les membres publics ne devraient pas être «virtuels» | ✓ | - |
| Miko_3220 | Logique '&&' ou '||' Les conditions utilisant «vrai» ou «faux» doivent être simplifiées | ✓ | ✓ |
| Miko_3221 | GethashCode Overrides devrait utiliser 'HashCode.Comphine' | ✓ | ✓ |
| Miko_3222 | Les comparaisons de chaînes peuvent être simplifiées | ✓ | ✓ |
| Miko_3223 | Les comparaisons de référence peuvent être simplifiées | ✓ | ✓ |
| Miko_3224 | Les comparaisons de valeur peuvent être simplifiées | ✓ | ✓ |
| Miko_3225 | Les comparaisons redondantes peuvent être simplifiées | ✓ | ✓ |
| Miko_3301 | Favoriser les corps d'expression lambda au lieu de blocs d'expression Lambda entre parenthèses pour les instructions uniques | ✓ | ✓ |
| Miko_3302 | Favoriser les corps d'expression lambda simples au lieu de corps d'expression Lambda entre parenthèses pour les paramètres uniques | ✓ | ✓ |
| Miko_3401 | Les hiérarchies de l'espace de noms ne devraient pas être trop profondes | ✓ | - |
| Miko_3501 | Ne supprimez pas les avertissements nullables sur les opérateurs de climatisation nul | ✓ | ✓ |
| Miko_3502 | Ne supprimez pas les avertissements nullables sur les appels LINQ | ✓ | ✓ |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_4001 | Les méthodes avec le même nom doivent être commandées en fonction du nombre de leurs paramètres | ✓ | ✓ |
| Miko_4002 | Les méthodes avec le même nom et l'accessibilité doivent être placées côte à côte | ✓ | ✓ |
| Miko_4003 | Les méthodes à disposer doivent être placées directement après les constructeurs et les finalisateurs | ✓ | ✓ |
| Miko_4004 | Les méthodes à disposer doivent être placées avant toutes les autres méthodes de la même accessibilité | ✓ | ✓ |
| Miko_4005 | L'interface qui donne un type son nom doit être placée directement après la déclaration du type | ✓ | ✓ |
| Miko_4007 | Les opérateurs doivent être placés avant les méthodes | ✓ | ✓ |
| Miko_4008 | Les méthodes GethashCode doivent être placées directement après les méthodes égales | ✓ | ✓ |
| Miko_4101 | Les méthodes d'initialisation de test doivent être commandées directement après les méthodes ponctuelles | ✓ | ✓ |
| Miko_4102 | Les méthodes de nettoyage de test doivent être commandées après les méthodes d'initialisation des tests et avant les méthodes de test | ✓ | ✓ |
| Miko_4103 | Les méthodes d'initialisation de test unique doivent être commandées avant toutes les autres méthodes | ✓ | ✓ |
| Miko_4104 | Les méthodes de nettoyage de test unique doivent être commandées directement après des méthodes d'initialisation de test unique | ✓ | ✓ |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_5001 | Les méthodes de «débogage» et «debugformat» ne doivent être invoquées qu'après «isdebugenabled» | ✓ | ✓ |
| Miko_5002 | Les méthodes «xxxformat» doivent être invoquées avec plusieurs arguments uniquement | ✓ | ✓ |
| Miko_5003 | Les méthodes de journal correctes doivent être invoquées pour des exceptions | ✓ | - |
| Miko_5010 | N'utilisez pas 'object.equals ()' sur les types de valeur | ✓ | ✓ |
| Miko_5011 | Ne pas concaténer les chaînes avec + = opérateur | ✓ | - |
| Miko_5012 | N'utilisez pas de «rendement de rendement» pour les structures définies récursives | ✓ | - |
| Miko_5013 | Ne créez pas de tableaux vides | ✓ | ✓ |
| Miko_5014 | Ne créez pas de listes vides si la valeur de retour est en lecture seule | ✓ | ✓ |
| Miko_5015 | Ne pas intervenir les littéraux des cordes | ✓ | ✓ |
| Miko_5016 | Utilisez un hashset pour les recherches dans 'list.removeall' | ✓ | - |
| Miko_5017 | Les champs ou variables attribués avec des littéraux de cordes doivent être constants | ✓ | ✓ |
| IDENTIFIANT | Titre | Activé par défaut | CodeFix disponible |
|---|---|---|---|
| Miko_6001 | Les déclarations du journal doivent être entourées de lignes vierges | ✓ | ✓ |
| Miko_6002 | Les déclarations d'affirmation doivent être entourées de lignes vierges | ✓ | ✓ |
| 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 | 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 | ✓ | ✓ |
