Analyse de code statique - Lesquels activer en premier?

Question

Nous utilisons VS2008 avec le jeu de règles d'analyse de code statique intégré.
Nous avons une solution C # relativement importante (plus de 150 projets) et, bien que certains projets (& Lt; 20) utilisent religieusement l’analyse de code statique, la plupart ne le font pas. Nous voulons commencer à appliquer l'analyse de code statique à tous les projets, mais l'activation de toutes les règles créerait une énorme distraction pour nos projets actuels. Laquelle des nombreuses règles d’analyse de code statique disponibles devrions-nous activer en premier? Quelles règles ont le meilleur rapport qualité-prix? Si vous pouviez me donner votre top 20 des priorités, je l'apprécierais beaucoup.
Merci d'avance,
--Ed.S.

Answer 1

Les toutes premières règles que vous devez activer pour un projet sont celles pour lesquelles vous n'avez encore aucune violation dans ce projet. Cela vous permettra d'éviter d'introduire de nouveaux problèmes sans vous coûter un effort de nettoyage supplémentaire.

Pour le reste, étant donné que vous utilisez déjà l’analyse de code sur d’autres projets, votre meilleure contribution pour laquelle les règles risquent d’être violées avec des conséquences graves est probablement celle des développeurs qui travaillent sur ces projets. Si vous ne disposez pas de suffisamment de chevauchements entre les projets pour obtenir des commentaires significatifs de la part des développeurs, vous pouvez envisager de commencer par les règles incluses dans Règles minimales recommandées par Microsoft définies dans Visual Studio 2010.

Si vous envisagez de nettoyer réellement les violations existantes dans un projet donné, vous pouvez vouloir envisagez d’utiliser FxCop au lieu de VS Code Analysis jusqu'à la fin du nettoyage. Cela vous permettrait d'activer immédiatement les règles tout en conservant & "Pour le nettoyage"! exclusions de violations existantes en dehors de votre code source.

Answer 2

Étant donné que les règles Studio sont similaires aux règles de FxCop, je peux vous dire celles que je voudrais activer dernier .

Si l'internationalisation n'est pas à l'horizon, désactivez les règles de la mondialisation.

Désactivez initialement les règles de performance. Optimisez lorsque vous en avez besoin.

Adaptez les autres à votre équipe et à vos projets. Désactiver les règles individuelles qui ne sont pas applicables. En particulier, il peut être nécessaire de modifier les règles de dénomination.

EDIT: Le plus important est de réduire le bruit. Si chaque projet comporte 200 avertissements et le reste pendant des mois, tout le monde les ignorera. Activez les règles qui importent à votre équipe, nettoyez le code pour qu'il passe à 100% (ou supprimez les exceptions - il y aura des exceptions; ce sont des instructions), puis appliquez le code pour le garder propre.

Answer 3

Si vous voulez localiser votre projet / qu'il va être utilisé dans différents pays, activez définitivement les règles de localisation. Il trouvera tous les appels à toutes sortes de fonctions Format / Analyse qui ne spécifient pas CultureInfo. Les bogues impliquant CultureInfo non spécifiés sont difficiles à trouver dans les tests, mais ils vous mordront vraiment dans le cul, lorsque votre client français vous demandera: pourquoi votre programme ne fonctionne pas / plante les numéros avec & "; &" ; comme séparateur décimal.

Answer 4

D'après mon expérience, les avertissements d'analyse de code de tous types indiquent des bogues ou des défauts "cachés" dans votre code. Les résoudre peut résoudre certains problèmes réels. Je n'ai pas trouvé de liste d'avertissements que je voudrais désactiver.

Au lieu de cela, je les allumerais pour un projet à la fois et corrigerais tous les avertissements de ce projet avant de passer au suivant.

Si vous souhaitez désactiver des fonctionnalités, je vous conseillerais de ne pas vérifier les règles de dénomination (sauf si vous envoyez une bibliothèque, des API ou d'autres méthodes exposées de manière externe) et des règles de globalisation. (sauf si vos applications utilisent activement la globalisation). Cela dépend un peu de votre situation qui a du sens.

Answer 5

Je suis plutôt d'accord avec La réponse de Jeroen Huinink .

J'allumerais toutes les règles qu'un projet devrait suivre, à votre avis, et les corrigerais dès que possible. Vous n'avez pas besoin de toutes les corriger maintenant, mais au fur et à mesure que vous corrigez un défaut ou refactorisez une méthode dans un module, vous pouvez toujours nettoyer les problèmes décelés par l'analyse statique dans cette méthode ou ce module. Le nouveau code doit adhérer à vos règles et le code existant doit être transformé en adhésion le plus rapidement possible, mais vous n'avez pas besoin de tout laisser tomber pour que cela se produise.

Votre équipe de développement peut également examiner les problèmes d'un projet et les hiérarchiser, peut-être en archivant les défauts de votre système de suivi des problèmes pour les problèmes les plus critiques, afin qu'ils soient traités rapidement par le développeur approprié.