Почему я не вижу более строгой оценки чаще?

Question

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

Вот пример того, что я имею в виду.

{
        int h = 0;
        foreach (var item in photos)
        {
            buffer = t.NewRow();
            h = item.IndexOf("\\x\\");
            buffer["name"] = item.Substring(h, item.Length - h);
            t.Rows.Add(buffer);
        }
}

В этом примере я ограничил область действия h, не инициализируя ее на каждой итерации.

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

Answer 1

Ну, в этом случае вы присваиваете новое значение на каждой итерации в любом случае , без использования "старого" значения - поэтому я бы использовал:

foreach (var item in photos)
{
    buffer = t.NewRow();
    int h = item.IndexOf("\\x\\");
    buffer["name"] = item.Substring(h, item.Length - h);
    t.Rows.Add(buffer);
}

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

Смею сказать, что это может быть полезно в старом стиле C - но когда я пишу C #, я не вижу причин делать вещи, которые полезны в C, но не улучшают мой C #:)

Answer 2

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

    foreach (var item in photos)
    {
        int h = 0;
        buffer = t.NewRow();
        h = item.IndexOf("\\x\\");
        buffer["name"] = item.Substring(h, item.Length - h);
        t.Rows.Add(buffer);
    }

Компилятор распознает, что «инициализация» h на самом деле не используется, поэтому он не потрудится (даже на первой итерации цикла). Компилятор также не потрудится даже перераспределить h (возможно, это будет просто регистр).

Однако, если бы h был типом объекта в C ++, у которого был конструктор / деструктор, выполняющий работу, которую компилятор не мог оптимизировать, он мог бы заплатить, чтобы вывести объявление h из цикла.

Answer 3

Большинство разработчиков довольно небрежно относятся к области видимости.Я работал с разработчиками, которые охватывают все как можно выше, чтобы избежать необходимости выделять «лишние» переменные.Обычно это происходит из-за того, что люди думают, что они экономят память, потому что не понимают переменные стека.Тем не менее, вы поступаете правильно, хотя экономия, которую вы получаете, инициализируя переменную вне цикла foreach, минимальна, и я, вероятно, не стал бы беспокоиться.

Answer 4

Пример плохой, как указывали другие.

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