Какое настраиваемое правило проверки статического кода вы хотите видеть в FxCop и/или жандарме?Какое правило вы хотите, чтобы FxCop/жандарм имел?
Зачем вам нужно добавить правило, например, какие преимущества и т.д.?
Как могло бы быть реализовано ваше правило?
Лично я бы предпочел не использовать IDisposable реализации в using заявлениях.
Так что, если у вас такой код:
var fs = new FileStream(...);
// Other code.
fs.Dispose();
Было бы сказать вам, чтобы использовать его в using заявлении.
Выгода будет заключаться в том, что она предупредит вас о случаях, когда вы не знаете, где объекты, которые должны быть удалены, не будут своевременно удалены.
Однако, есть достаточно времени, когда это допустимая ситуация, чтобы НЕ объявить IDisposable реализаций в используемом утверждении для такого правила, чтобы это стало очень быстро. Чаще всего этот случай принимает реализацию IDisposable как параметр метода.
Что я не имею в виду обыкновений классов, где детали реализации устранить необходимость вызова Dispose, (например, MemoryStream или DataContext); те, которые осуществляют IDisposable, и должны всегда иметь Dispose, вызываемые на них, вне зависимости от . детали, так как всегда лучше указывать на выставленный контракт.
@Ian Ringrose: Обновлен мой ответ, чтобы уточнить. – casperOne
VS2010 Анализ кода имеет правило неразрывности для этого: http://msdn.microsoft.com/en-us/library/ms182289%28VS.100%29.aspx –
Я хочу очень быстро определить и реализовать свои правила. Я попробовал это однажды для FxCop, но я нашел API не очень понятным - и документации не было слишком много. Я использовал FxCop 1,36, может быть, все изменилось ...
Так что я хотел бы видеть FxCop имея четкий и простой в использовании интерфейс ... это было бы здорово :)
Правила, я пытался реализовать были:
Bas Я хотел бы обеспечить соблюдение xml-комментариев для непубличных участников.
Используйте StyleCop для этого, у него есть правило для встроенного. XML-комментарии все равно не компилируются в сборку, поэтому FXCop не может определить, определены ли они или нет, поскольку он анализирует только собранные сборки. –
Я знаю о StyleCop, но в это время я хотел реализовать его в FxCop - и я сделал это. Вы правы, вам нужно загрузить xml-файлы по отдельности. – tanascius
Мне бы очень хотелось, чтобы бинарный анализ был достаточно умным, чтобы распознавать возможность интерфейса.
Если он может определить приближение к определенным типам и их членам, если есть домены, которые могут быть экстраполированы в интерфейс.
Очевидно, что это не должно быть больше, чем предупреждение, так как иногда ему явно не нужен интерфейс.
Одумав об этом, я также хотел бы, чтобы бинарный анализ был достаточно умным, чтобы проверить возможное понижение модификаций доступа.
Невозможно определить, может ли класс, свойство или метод быть более ограниченным.
FXCop не выполняет проверку статического кода, он проверяет скомпилированную сборку (IL). Статический код analisys выполняется через StyleCop. –
@BeowulfOF, я бы сказал, что FXCop проверил статический код, он просто не проверяет количество пробелов, которые у вас есть на каждой стороне «=» и т. Д. StyleCop делает больше проверки стиля, например. id не отслеживает поток управления между методами и т. д. –
Microsoft заявляет, что только сборки анализируются FXCop, а не исходным кодом. http://msdn.microsoft.com/en-us/library/bb429476%28VS.80%29.aspx –