Существует ли правило .Net StyleCop, которое предупреждает о блокировке (this), блокировке (typeof, lock (<string obj> и т. Д.)?

Question

Эти 3 типа блокировки явно плохие. Какой другой тип блокировки плох? Существуют ли правила Stylecop / FxCop, которые бы это уловили? Если нет, то не могли бы вы помочь мне с реализацией пользовательских правил? Код для всех них должен быть одинаковым, верно?

Спасибо.

Answer 1

семплов (вам может потребоваться разрешить всплывающие окна в вашем браузере) Отладки приложений Microsoft .NET * книги Джона Роббинса содержат источники для таких правил FxCop (DoNotLockOnPublicFields, DoNotLockOnThisOrMe, DoNotLockOnTypes , так далее.). Похоже, они изначально были созданы для FxCop 1.35, тогда как версия в VS 2008 и последняя автономная версия - 1.36 (не говоря уже о VS2010). Поэтому им, возможно, понадобится немного подправить, YMMV.

Существует также правило CA2002 (не блокировать объекты со слабой идентичностью), которое проверяет наличие таких вещей, как lock(typeof(...)), но не lock(this)

Answer 2

По сути, вы не должны блокировать какие-либо внешние объекты, если только это не является конкретно блокирующим объектом (например, свойство SyncRoot в неуниверсальном ICollection, для которого было разработано). Это может привести к тому, что другие «пользователи» ссылки также будут заблокированы, что приведет к нежелательной блокировке или даже к взаимной блокировке.

Очевидно, this и typeof() по определению являются внешними объектами. Строки являются неизменяемыми, а строковые литералы - интернированными, так что одна и та же ссылка может находиться в unse в разных местах, даже если вы непосредственно присвоили ее в своем объекте.

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