Quelles sont les règles FxCop "à suivre" pour tout développeur C #?

Question

Je prévois de commencer à l'aide de FxCop dans l'un de nos projet en cours. Mais, quand je l'ai essayé avec la sélection de toutes les règles, il semble que j'ai à faire beaucoup de changements dans mon code. Être un "membre de l'équipe" je ne peux pas tout de suite commencer à faire ces changements, comme la convention d'affectation de noms, etc. de toute façon, je voudrais commencer à utiliser FxCop avec un minimum de règles et permettrait d'augmenter progressivement l'ensemble de règles que nous dépasse. Pouvez-vous me suggérer certains doivent avoir des FxCop règles qui je devrais commencer à suivre. Ou avez-vous suggérer la meilleure approche?

Remarque: la Plupart de mon code est en C#.

Answer 1

Sur notre code le plus important:

• Traitez les avertissements comme des erreurs (niveau 4)
• FxCop doit passer à 100% (aucun ignore généralement autorisé)
• Gendarme utilisé comme ligne directrice (parfois en conflit avec FxCop)

Croyez-le ou non, FxCop vous apprend beaucoup sur la façon d'écrire un meilleur code ... un excellent outil! Donc pour nous, toutes les règles sont tout aussi importantes.

Answer 2

À mon avis, procédez de la manière suivante:

Pour tout nouveau projet, suivre toutes les règles FxCop. Vous souhaiterez peut-être désactiver certains d'entre eux, car tout ne fera sens pour votre projet. Pour un projet existant, suivre les règles de ces catégories, comme un ensemble minimum:

• La mondialisation
• L'interopérabilité
• Sécurité
• Performance
• La portabilité

Puisque ceux-ci sont généralement seulement quelques violations des règles dans un projet existant, par rapport aux autres catégories, mais peut améliorer la qualité de votre application. Lorsque ces règles sont claires, essayez de corriger les catégories suivantes:

• Conception
• L'utilisation de la

Puisque ce sera plus facile pour vous de repérer les bugs qui ont à voir avec les violations, mais vous aurez une grande quantité de violations dans le code existant.

Toujours trier les violations par le niveau de correction de la catégorie et de commencer par les critiques. Ignorer les mises en garde pour l'instant.

Dans le cas où vous ne le saviez pas, il y a aussi StyleCop disponible auprès de Microsoft, la vérification de votre code sur le niveau de la source. Assurez-vous d'activer MSBuild intégration lors de l'installation.

Answer 3

Certaines des règles nous éviter des bugs ou des fuites:

• Ne pas attraper général, les types d'exception (Peut-être la meilleure règle pour nous. Selon les cas, il peut être facile ou difficile à appliquer)
• Test pour NaN correctement (facile à appliquer)
• Jetable champs doivent être éliminés (assez facile à mettre en œuvre)
• Jetez doit appeler de la base de disposer (assez facile à mettre en œuvre)
• Jetable types de déclarer finaliseur (assez facile à mettre en œuvre)

Certains nous aider à avoir une meilleure conception, mais attention, ils peuvent vous conduire à de gros refactoring centrale quand l'API est impacté. Nous aimons

• Les propriétés de Collection doit être en lecture seule (difficile à appliquer dans notre cas)
• Ne pas exposer liste générique
• le membre ne doit pas exposer certains types de béton
• Examen usuned paramètres (Améliore facilement votre API)

Quelqu'un sur notre projet essayé les règles de performance avec aucune amélioration. (En fait, ces règles sont sur la micro-optimisation, qui ne donne aucun résultat, si pas de goulot d'étranglement d'identification montre microoptimizing est nécessaire). Je suggère de ne pas commencer avec ceux-ci.

Answer 4

Une alternative à FxCop serait d'utiliser l'outil de NDepend qui permet d'écrire des Règles de Code C# Requêtes LINQ (à savoir CQLinq). Avertissement: je suis l'un des développeurs de l'outil

Plus de 200 règles de code sont proposées par défaut. Personnalisation des règles existantes ou à créer vos propres règles est simple grâce à la bien connue C# syntaxe LINQ.

NDepend chevauche FxCop sur un code de règles, mais propose beaucoup de code unique de règles. Voici quelques règles que je classerais comme doit suivre:

• Éviter la diminution de la couverture de code par les tests de types
• Éviter de faire des méthodes complexes, même les plus complexes (Source CC)
• Éviter de transformer immuable dans une mutable
• Les remplacements de la Méthode() doit d'appel de base.Méthode()
• Éviter le pattern Singleton
• Types avec des champs d'instance doit être à usage unique
• Jetables avec des types de ressources non managées doit déclarer finaliseur
• Éviter les espaces de noms mutuellement dépendants
• Éviter les espaces de noms de dépendance cycles
• Couche d'INTERFACE utilisateur ne doit pas utiliser directement DB types
• API dernières Modifications: Méthodes
• Méthodes complexes partiellement couverts par des tests doivent être couvertes à 100%
• Potentiellement morts Types
• Les Structures doivent être immuable
• Éviter de nommer les types et les espaces de noms avec le même identifiant

Notez que les Règles peuvent être vérifiées vivre dans Visual Studio et au Processus de construction du temps, dans un générés HTML+javascript rapport.

Answer 5

Activez une règle à la fois. Corrigez ou excluez tous les avertissements signalés, puis démarrez le suivant.