StyleCop SA1124 DoNotUseRegions разумен? [закрытый]
Один из способов сделать это - объявить var в ваших корневых модулях и импортировать / ссылаться на них в той же области видимости, когда вы устанавливаете и ссылаетесь.
Представьте себе структуру каталогов ваших модулей следующим образом
my_module/
- __init__.py
- another_module.py
- utils/
- __init__.py
- and_so_on.py
в my_module / __ init__.py, объявите ваш __debug__ var
__debug__ = False
в вашем примере кода
import my_module
class ABC:
def __init__(self):
pass
def some_function()
if my_module.__debug__ is True:
print "Some debug logs"
Затем, прежде чем вы на самом деле выполните код, установите свой флаг отладки на False, импортируя и ссылаясь одинаково
import my_module
my_module.__debug__ = True
Пока вы импортируете и ссылаетесь на переменную того же IE: [1111 ]
import my_module
if my_module.__debug__ is True:
print("IN DEBUG")
Он сохранит свое значение на протяжении всего твоего исполнения
3 ответа
Это будет дело личных предпочтений. Единственное, что здесь имеет значение, - это то, что вы и ваша команда предпочитаете . Забудьте, что говорит коп стиля, вы это читаете, вы поддерживаете его, независимо от того, с регионами или без них лучше для вас, это все, что имеет значение.
Если вы выпускаете его как проект с открытым исходным кодом ... и это мое мнение здесь , я думаю, что то же самое. Используйте то, что удобнее для основной команды. Если у вас на борту намного больше членов команды и больше участников, повторно посетите проблему позже, это всегда можно изменить.
Мне нравятся регионы и моя команда, и я чувствую, что код более удобен для чтения.
Вот времена, когда я люблю их ...
Если у вас есть корпоративный стандарт для написания модульных тестов с Arrange 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?) С использованием INotifyPropertyChanged - это 10 строк (9 строк плюс пробел), поэтому хорошо спроектированный и хорошо написанный объект ViewModel только с 5 свойствами означает, что раздел свойств содержит не менее 50 строк кода.
Мне также особенно они нравятся, когда я использую чужой плохо написанный код. Глупо полагать, что вы всегда можете использовать рефакторинг для идеального дизайна. Например, у вас есть класс с 2500 строками или более. Конечно, это, вероятно, можно было бы написать лучше, но вы этого не делали, это работает, и это проверено, и у вашего бизнеса есть код в «только исправить», поэтому рефакторинг не разрешен. Вы можете сделать слишком большой класс (плохо написанный или нет) гораздо более читабельным, используя операторы #region. Вы получаете множество преимуществ читабельности при разделении задач без фактического разделения класса, а затем, как только код выйдет из блокировки и вы сможете выполнить рефакторинг, большая часть работы по разделению может быть уже выполнена с использованием #regions, и вы можете преобразовать регионы в отдельный класс.
Я думаю, что регионами можно злоупотреблять, но это полезный метод, позволяющий читателю сосредоточиться на определенных областях кода за раз.
Однако я бы избегал слишком большого количества уровней вложенности.