StyleCop SA1124 DoNotUseRegions разумно?

Question

SA1124 DoNotUseRegions предлагает не использовать регион нигде. Это действительно разумно?

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

Я хотел бы удалить это правило, проверяя стиль кода. Могу ли я узнать ваше мнение по этому правилу?

Answer 1

Это будет личное предпочтение. Единственное, что имеет значение здесь, это , что вы и ваша команда предпочитаете. Забудьте, что говорит полицейский стиль, вы его читаете, вы его поддерживаете, независимо от того, работает ли с вами или без регионов, это все, что имеет значение.

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

Answer 2

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

Однако я бы избегал слишком много уровней гнездования.

Answer 3

Интересно, является ли это правило побочным эффектом других более общепринятых правил, таких как заказ частных/защищенных/публичных членов. Следуя этим правилам упорядочения, во многих случаях обязательно будет ломаться логическая группировка #regions, поэтому они станут взаимоисключающими.

Answer 4

Больше нет необходимости в регионах в хорошо написанном коде. Когда-то было полезно спрятать сгенерированный компьютером код. Теперь этот код идет в отдельный файл. Регионы все еще могут использоваться для скрытия плохо написанного кода.

Answer 5

По моему мнению, существует исключение где # область/# endregion имеет смысл: При реализации интерфейсов!

например.

#region Implementation of IDisposable 
public void Dispose() 
{ 
    // implementation here ... 
} 
#endregion 

Во всех остальных случаях вы не должны использовать #region, как они устарели (я предполагаю, где созданы для сокрытия сгенерированного кода - .net-1.0 и .net-1.1, но теперь есть частичные классы для этого)

--Harald-Рене Flasch (ака hfrmobile)

Answer 6

Мне нравится регионы и моя команда, и я чувствую код более читаемым с ними.

Вот те времена, когда я их люблю ...

Если у вас есть стандарт компании, чтобы писать модульные тесты с Устройте Act Assert (AAA), то вам может потребоваться юнит-тесты, чтобы выглядеть следующим образом

[test] 
public void MyFunction_Test 
{ 
#region Arrange 
#endregion  

#region Act 
#endregion 

#region Assert 
#endregion 
} 

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

Другое место, где мне нравится регион, это код, когда вы знаете, что скоро собираетесь удалить код.

#region Drop this region next version when we drop 2003 support 
public void DoSomeThingWithWindowsServer2003() 
{ 
    // code the is for Windows 2003 only 
} 
#endregion 

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

#region Constructors 
#endregion 

#region Properties 
#endregion 

#region Events 
#endregion 

#region Methods 
#endregion 

#region Enums 
#endregion 

Обычно класс не будет иметь все из них (если это вы можете удивиться, если вы делаете слишком много в одном классе), но я думаю, что если вы ищете один метод или свойство, его приятно иметь одно место для просмотра. Не говоря уже о свойствах в ViewModel (MVVM anybody?), Использующем INotifyPropertyChanged, это 10 строк (9 строк плюс пробел), поэтому хорошо продуманный и хорошо написанный объект ViewModel с только 5 свойствами означает, что раздел свойств имеет не менее 50 строк кода.

Мне также особенно нравятся они при использовании плохо написанного кода другого человека. Глупо предположить, что вы всегда можете реорганизовать, чтобы использовать идеальный дизайн. Например, у вас есть класс с 2500 строк и более. Уверен, что это, вероятно, могло быть написано лучше, но вы этого не сделали, оно работает, и оно проверено, и ваш бизнес имеет код в «фиксированной» блокировке, поэтому рефакторинг не разрешен. Вы можете сделать слишком большой класс (плохо написанный или нет) гораздо более читаемым с помощью операторов #region. Вы получаете много преимуществ чтения от разделения проблем без фактического разделения класса, а затем, как только код выходит из строя, и вы можете реорганизовать, большая часть работы по разделению уже может быть выполнена с помощью #regions, и вы можете конвертировать ваши регионов в отдельный класс.

Answer 7

Из моего опыта они не должны использоваться вообще. Младшие разработчики склонны злоупотреблять ими и создавать слишком сложные классы, сложность которых «умственно» скрыта за многочисленными регионами.