Какое правило Вам жаль, что FxCop/Gendarme не имел?
Какой определимый статический код, проверяющий правило, Вы хотите видеть добавленный к FxCop и/или Жандарму?
Почему сделать Вас, хотят видеть правило, добавленное, например, каковы преимущества и т.д.?
Как Ваше правило могло быть реализовано?
4 ответа
Лично я бы предпочел не использовать IDisposable реализации в с использованием операторов .
Итак, если бы у вас был такой код:
var fs = new FileStream(...);
// Other code.
fs.Dispose();
Он бы сказал вам использовать его в операторе using .
Преимущество заключается в том, что он будет предупреждать вас о случаях, когда вы можете не знать, где объекты, которые следует утилизировать, не утилизируются своевременно.
Тем не менее, бывает достаточно случаев, когда допустимая ситуация - НЕ объявлять реализации IDisposable в операторе using, чтобы подобное правило очень быстро стало проблемой. Чаще всего в этом случае в качестве параметра метода используется реализация IDisposable .
То, что я делаю , а не , означает использование классов, где детали реализации устраняют необходимость вызова Dispose , (например, MemoryStream или DataContext ); они реализуют IDisposable и всегда должны вызывать Dispose , независимо от деталей реализации , поскольку всегда лучше кодировать в соответствии с раскрытым контрактом.
Я хотел бы очень быстро определить и внедрить свои собственные правила. Я попробовал это однажды для FxCop, но обнаружил, что API не очень понятен - да и документации было не так уж и много. Я использовал FxCop 1.36, может что-то изменилось ...
Так что я бы хотел, чтобы у FxCop был понятный и простой в использовании интерфейс ... это было бы здорово :)
Я пытался реализовать следующие правила:
- DocumentInternalMethods
- DocumentInternalTypes
- ...
В основном я хотел применить xml-комментарии к непубличным членам.
Мне бы очень хотелось, чтобы двоичный анализ был достаточно умным, чтобы распознавать возможность интерфейса.
Если бы он мог определить, приближаясь к определенным типам и их членам, есть ли общие объекты, которые можно экстраполировать в интерфейс.
Ясно, что это не должно быть больше, чем предупреждение, поскольку иногда желательно явно не использовать интерфейс.
Поразмыслив над этим, я тоже хотел бы, чтобы двоичный анализ был достаточно умен, чтобы проверять возможное понижение версии модификаторов доступа.
Нетрудно определить, могут ли быть более ограничены класс, свойство или метод.