Какое правило вы хотели бы иметь FxCop / Жандарм?

Question

Какое определяемое правило проверки статического кода вы хотите добавить в FxCop и / или Gendarme?

Почему вы хотите добавить правило, например, каковы преимущества и т. Д.?

Как можно реализовать ваше правило?

Answer 1

Я бы хотел очень быстро определить и реализовать свои собственные правила. Я попробовал это один раз для FxCop, но я обнаружил, что API не очень понятен - и не было слишком много документации вокруг. Я использовал FxCop 1.36, возможно, все изменилось ...

Так что я бы хотел, чтобы у FxCop был понятный и простой в использовании интерфейс ... это было бы здорово :) 1003 *

Правила, которые я пытался реализовать, были:

• DocumentInternalMethods
• DocumentInternalTypes
• ...

По сути, я хотел применить xml-комментарии к закрытым членам.

Answer 2

Подумав об этом, я также хотел бы, чтобы бинарный анализ был достаточно умным, чтобы проверить возможное снижение рейтинга модификаторов доступа.

Нетрудно определить, может ли класс, свойство или метод быть более ограниченным.

Answer 3

Мне бы очень хотелось, чтобы бинарный анализ был достаточно умным, чтобы распознать возможность интерфейса.

Если бы он мог определить, приближаясь к определенным типам и их членам, есть ли общие объекты, которые можно экстраполировать в интерфейс.

Очевидно, что это не должно быть чем-то большим, чем предупреждение, поскольку иногда желательно явно не использовать интерфейс.

Answer 4

Лично я бы предпочел не использовать IDisposable реализации в using инструкциях.

Так что, если у вас был такой код:

var fs = new FileStream(...);

// Other code.

fs.Dispose();

Было бы сказано использовать его в выражении using.

Выгода будет состоять в том, что он будет предупреждать вас о случаях, когда вы, возможно, не знаете, где объекты, которые должны быть утилизированы, не утилизируются своевременно.

Однако, бывает достаточно, чтобы это была допустимая ситуация, чтобы НЕ объявлять IDisposable реализации в операторе using для правила, подобного этому, чтобы очень быстро стать болью. Чаще всего в этом случае берется реализация IDisposable в качестве параметра метода.

То, что я делаю не , означает использование классов, в которых детали реализации устраняют необходимость вызова Dispose, (например, MemoryStream или DataContext); они реализуют IDisposable и должны всегда вызывать Dispose независимо от деталей реализации , так как всегда лучше кодировать против выставленного контракта.