Существует ли правило.Net StyleCop, которое предупреждает о блокировке (это), блокировка (typeof, блокировка (<представляют obj в виде строки>, и т.д.?
Эти 3 типа блокировки по-видимому плохи. Что другой тип блокировки плох? Есть ли Stylecop / правила FxCop, которые поймали бы это? В противном случае затем помогите мне с реализацией пользовательского правила? Они кодируют для всех них, должно быть подобным, правильно?
Спасибо.
2 ответа
Примеры (вам может потребоваться разрешить всплывающие окна в браузере) книги Джона Роббинса Отладка приложений Microsoft .NET содержат исходные коды для таких файлов FxCop правила (DoNotLockOnPublicFields, DoNotLockOnThisOrMe, DoNotLockOnTypes и т. д.). Похоже, что они изначально были созданы для FxCop 1.35, тогда как версия в VS 2008 и последняя автономная версия - 1.36 (не говоря уже о VS2010). Так что им может потребоваться небольшая настройка, YMMV.
Существует также правило CA2002 (Не блокировать объекты со слабой идентификацией), которое проверяет такие вещи, как lock (typeof (...)) , но не замок (этот)
В принципе, вы не должны блокировать любой внешний объект, если только это не специально блокирующий объект (например, свойство SyncRoot на негенерической ICollection было предназначено для этого). При этом возникает риск того, что другие "пользователи" ссылки также заблокируют ее, что приведет к нежелательной блокировке или даже к тупику.
Очевидно, что this и typeof() по определению являются внешними объектами. Строки неизменяемы, а строковые литералы все интернированы, так что одна и та же ссылка может находиться в разных местах, даже если вы напрямую присвоили ее в своем объекте.
Я не знаю правила StyleCop для таких случаев, но у меня нет хорошего обзора того, что доступно для StyleCop или FxCop, так что вполне может быть что-то в природе для проверки таких случаев. Я бы проверил синхронизацию только для приватных членов, которые не являются строками и не возвращаются напрямую ни в одном свойстве или методе.