Я иногда использую фигурные скобки для изоляции блока кода для избегания использования по ошибке переменной позже. Например, когда я поместил несколько SqlCommand
s в том же методе, я часто блоки кода вставки копии, заканчивающиеся путем смешивания имен и выполнения дважды некоторых команд. Добавление фигурных скобок помогает избежать этой ситуации, потому что использование несправедливости SqlCommand
в неправильном месте приведет к ошибке. Вот иллюстрация:
Collection<string> existingCategories = new Collection<string>();
// Here a beginning of a block
{
SqlCommand getCategories = new SqlCommand("select Title from Movie.Category where SourceId = @sourceId", sqlConnection, sqlTransaction);
getCategories.Parameters.AddWithValue("@sourceId", sourceId);
using (SqlDataReader categoriesReader = getCategories.ExecuteReader(System.Data.CommandBehavior.SingleResult))
{
while (categoriesReader.Read())
{
existingCategories.Add(categoriesReader["Title"].ToString());
}
}
}
if (!existingCategories.Contains(newCategory))
{
SqlCommand addCategory = new SqlCommand("insert into Movie.Category (SourceId, Title) values (@sourceId, @title)", sqlConnection, sqlTransaction);
// Now try to make a mistake and write/copy-paste getCategories instead of addCategory. It will not compile.
addCategory.Parameters.AddWithValue("@sourceId", sourceId);
addCategory.Parameters.AddWithValue("@title", newCategory);
addCategory.ExecuteNonQuery();
}
Теперь, StyleCop отображает предупреждение каждый раз, когда блок следует за пустой строкой. С другой стороны, помещение пустой строки сделало бы код намного тяжелее для понимания.
// Something like:
Collection<string> existingCategories = new Collection<string>();
{
// Code here
}
// can be understood as (is it easy to notice that semicolon is missing?):
Collection<string> existingCategories = new Collection<string>()
{
// Code here
}
Так,
Есть ли что-то не так в использовании фигурных скобок для создания блоков кода только в переменных целях объема?
Если это в порядке, как сделать это более читаемым, не нарушая правила StyleCop?
Я не думаю, что есть что-то плохое в использовании фигурных скобок только для ограничения области видимости - иногда это может быть весьма полезно.
Показательный пример: однажды я наткнулся на библиотеку профилирования, которая использовала объекты Profile
для определения временных участков кода. Они работали, измеряя время от их создания до разрушения, и поэтому лучше всего работали, создаваясь в стеке, а затем уничтожая, когда они выходили из области видимости, таким образом измеряя время, проведенное в этой конкретной области. Если вы хотите отследить время для чего-то, что по своей сути не имеет собственной области видимости, то добавление дополнительных фигурных скобок для определения этой области, вероятно, было бы лучшим выходом.
Что касается удобочитаемости, я могу понять, почему StyleCop не нравится, но любой, у кого есть опыт работы с C / C ++ / Java / C # / ... знает, что пара скобок определяет область видимости, и это должно быть довольно очевидно это то, что вы пытаетесь сделать.
Нет ничего плохого как такового в блокировке кода, но вам нужно подумать, зачем вы это делаете.
Если вы копируете и вставляете код, то, скорее всего, вы находитесь в ситуации, когда вам следует провести рефакторинг кода и создать функции, которые вы будете вызывать многократно, а не выполнять похожие, но разные блоки кода многократно.
Используйте оператор using
вместо простых фигурных скобок.
Это позволит избежать предупреждений, а также сделает ваш код более эффективным с точки зрения ресурсов.
С более широкой точки зрения вам следует рассмотреть возможность разделения этого метода на более мелкие. Использование одного SqlCommand
, за которым следует другой, обычно лучше выполнять, вызывая один метод, а затем другой. Затем каждый метод будет использовать свой собственный локальный SqlCommand
.
Я думаю, что такие блоки - хорошая идея, я их часто использую. Это полезно, когда вам нужно разделить блоки кода, которые слишком малы для извлечения в метод, или когда метод состоит из нескольких блоков кода , которые выглядят друг на друга, но с другой логикой. Это позволяет давать переменным одинаковые имена без конфликтов имен, и это делает тело метода более читабельным.
Кстати, на мой взгляд, у StyleCop есть набор правил по умолчанию с большим количеством правил, целесообразность которых спорна.
Я бы сказал, что если бы я работал над этим кодом после вас, я бы немного сбился с пути из-за вашего использования области видимости. Это, черт возьми, не обычная практика.
Я бы посчитал это запахом, когда вы это делаете. Я думаю, что лучше было бы разделить каждую область видимости на отдельный метод с полностью описательными именами и документацией.