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