Разве неправильно использовать фигурные скобки в переменных целях объема?

Я иногда использую фигурные скобки для изоляции блока кода для избегания использования по ошибке переменной позже. Например, когда я поместил несколько SqlCommands в том же методе, я часто блоки кода вставки копии, заканчивающиеся путем смешивания имен и выполнения дважды некоторых команд. Добавление фигурных скобок помогает избежать этой ситуации, потому что использование несправедливости 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
}

Так,

  1. Есть ли что-то не так в использовании фигурных скобок для создания блоков кода только в переменных целях объема?

  2. Если это в порядке, как сделать это более читаемым, не нарушая правила StyleCop?

19
задан Arseni Mourzenko 6 July 2010 в 19:01
поделиться

5 ответов

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

Показательный пример: однажды я наткнулся на библиотеку профилирования, которая использовала объекты Profile для определения временных участков кода. Они работали, измеряя время от их создания до разрушения, и поэтому лучше всего работали, создаваясь в стеке, а затем уничтожая, когда они выходили из области видимости, таким образом измеряя время, проведенное в этой конкретной области. Если вы хотите отследить время для чего-то, что по своей сути не имеет собственной области видимости, то добавление дополнительных фигурных скобок для определения этой области, вероятно, было бы лучшим выходом.

Что касается удобочитаемости, я могу понять, почему StyleCop не нравится, но любой, у кого есть опыт работы с C / C ++ / Java / C # / ... знает, что пара скобок определяет область видимости, и это должно быть довольно очевидно это то, что вы пытаетесь сделать.

7
ответ дан 30 November 2019 в 02:38
поделиться

Нет ничего плохого как такового в блокировке кода, но вам нужно подумать, зачем вы это делаете.

Если вы копируете и вставляете код, то, скорее всего, вы находитесь в ситуации, когда вам следует провести рефакторинг кода и создать функции, которые вы будете вызывать многократно, а не выполнять похожие, но разные блоки кода многократно.

22
ответ дан 30 November 2019 в 02:38
поделиться

Используйте оператор using вместо простых фигурных скобок.

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

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

13
ответ дан 30 November 2019 в 02:38
поделиться

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

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

5
ответ дан 30 November 2019 в 02:38
поделиться

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

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

3
ответ дан 30 November 2019 в 02:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: