Неправильно ли использовать фигурные скобки для целей переменной видимости?

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

Кстати, мое мнение StyleCop имеет правило по умолчанию набор с большим количеством правил, которые Целесообразность спорно.

Ответ 5

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

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

Ответ 6

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