- Je suis sur 4.3.3.0
- .net 3.5
- lots, toute la documentation et une collection d'autres.
- Aucune, IIRC.
- Dans le passé, je l'ai fait. Je n'ai actuellement aucune exigence de style de codage, mais auparavant je l'ai fait. Je crée des règles personnalisées pour eux quand je les ai.
- "Cliquez avec le bouton droit de la souris sur l'avertissement, Afficher l'aide en cas d'erreur". Mon favori est "ajouter le fichier Settings.StyleCop au dossier des éléments de la solution".
- Non, mais je le ferais si je le pouvais.
- FxCop. Yup, valeur infinie pour l'argent.
- Oui. Les règles que vous activez/désactivez doivent être entièrement guidées par les règles de codage que vous essayez de valider. La raison pour laquelle vous ne savez pas lequel utiliser est probablement parce que vous n'en avez pas. C'est donc la première chose que vous devriez faire, en créant un ensemble de directives de codage. Vous pouvez utiliser StyleCop pour déterminer les règles que vous souhaitez appliquer (commencez avec toutes les règles et supprimez-en une lorsque tout le monde est d'accord que cette règle ne fournit aucune valeur pour l'effort nécessaire pour le réparer). Cela semble un peu en arrière et éviterait la possibilité d'avoir une norme de codage qui n'était pas déjà appliquée par StyleCop, mais c'est certainement mieux que rien. Et ce serait un moyen rapide de générer des standards locaux. Une autre façon de le faire serait de chercher autour de existing published coding guidelines que votre équipe peut plus ou moins d'accord (1), puis en configurant StyleCop pour les appliquer. D'une manière ou d'une autre, il y a beaucoup à gagner à avoir un style de codage cohérent à travers le groupe, et StyleCop est le moyen de le renforcer.
- Les règles personnalisées sont géniales. Ne négligez pas la possibilité de désactiver une règle StyleCop et d'implémenter une «meilleure» version de la même règle.
(1) Il est comme garniture de pizza, il n'y a aucun moyen que vous allez obtenir un accord complet dans le groupe, mais un consensus général peut survenir
Merci, bonnes choses. Nous avons changé de C++ (ne peut pas le jeter, mais ne l'ajouterons pas beaucoup) à .Net. Les directives C++ existantes ont d'abord été appliquées à .Net, mais je vois un gros problème tel que nommer les variables membres comme m_ * - c'est une évidence. Si Stylecop vous force à utiliser ceci. * sur les membres, alors m_ est certainement redondant. C'est pourquoi la discussion sur ce qu'il faut garder et ce qu'il faut lâcher sera difficile, mais nécessaire. –