Минимизируйте область видимости переменной - Философия программирования

Совет минимизировать область видимости переменной общеизвестен. Минимальная область видимости это область видимости неименованной переменной, тем не менее часто избегают писать так:

    if (DoSomethingUseful(
        variable1.Method1(variable1A, variable1B),
        variable2.Method2(variable2A, variable2B),
        variable3.Method3(variable3A, variable3B)
    )) {
        . . .
    }

и пишут так:

    var par1 = variable1.Method1(variable1A, variable1B);
    var par2 = variable2.Method2(variable2A, variable2B);
    var par3 = variable3.Method3(variable3A, variable3B);
    if (DoSomethingUseful(par1, par2, par3)) {
        . . .
    }

I>    if (DoSomethingUseful(
I>        variable1.Method1(variable1A, variable1B),
I>        variable2.Method2(variable2A, variable2B),
I>        variable3.Method3(variable3A, variable3B)
I>    )) {
I>        . . .
I>    }

I>

I>и пишут так:

I>

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>    }
I>

А если так:

    var customer = variable1.Method1(variable1A, variable1B);
    var totalPrice = variable2.Method2(variable2A, variable2B);
    var discount = variable3.Method3(variable3A, variable3B);
    if (DoSomethingUseful(customer, totalPrice, discount)) 
    {
        . . .
    }

I>    if (DoSomethingUseful(
I>        variable1.Method1(variable1A, variable1B),
I>        variable2.Method2(variable2A, variable2B),
I>        variable3.Method3(variable3A, variable3B)
I>    )) {
I>        . . .
I>    }

I>

I>и пишут так:

I>

I>

В первом случае не разумно говорить об области видимгсти переменных, так как переменных собственно нет )))

Здравствуйте, Aikin, Вы писали:

A>А если так:
A>

A>    var customer = variable1.Method1(variable1A, variable1B);
A>    var totalPrice = variable2.Method2(variable2A, variable2B);
A>    var discount = variable3.Method3(variable3A, variable3B);
A>    if (DoSomethingUseful(customer, totalPrice, discount)) 
A>    {
A>        . . .
A>    }
A>

Это то же, что и мой второй вариант. Разумеется, вместо par1, par2 и par3 будут использованы более информативные имена, как впрочем и вместо variable1, Method1 и так далее. Так, в твоем примере Method1 будет скорее всего называться как-нибудь со словом Customer в имени, так что дополнительное именование переменной ничего не даст.

Здравствуйте, igna, Вы писали:

I>Это то же, что и мой второй вариант. Разумеется, вместо par1, par2 и par3 будут использованы более информативные имена, как впрочем и вместо variable1, Method1 и так далее.
Ну так надо было бы так и написать, а не вводить людей в заблуждения

I>Так, в твоем примере Method1 будет скорее всего называться как-нибудь со словом Customer в имени, так что дополнительное именование переменной ничего не даст.
Прошу переписать пример чтобы быделенное действительно имело место

Здравствуйте, Aikin, Вы писали:

A>Прошу переписать пример чтобы быделенное действительно имело место

        using (var serviceHost = new ServiceHost(
            typeof(MinimalistSelfHostedWebService),
            new Uri("http://localhost:8000/MinimalistSelfHostedWebService")
        )) {
            . . .
        }

        var baseAddress = new Uri("http://localhost:8000/MinimalistSelfHostedWebService");
        using (var serviceHost = new ServiceHost(typeof(MinimalistSelfHostedWebService), baseAddress)) {
            . . .
        }

На мой взгляд указание того, что URI является base address ничего не дает, зато объявление переменной заставляет смотреть, не используется ли она где-нибудь внутри using.

Здравствуйте, igna, Вы писали:

I>и пишут так:

I>

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>    }
I>

Вариантов несколько:
1) Повысить читабельность, так как имя переменной несет в себе смысл. Ибо из одного только вызова бывает непонятно, что возвращается. Ну представь: variable1.Method1(variable1A / 1.46 > object1.GetSomething() ? variable1A : variable1A * this.GetPar(), variable1B)

2) Удобство отладки. В отладчике можно глянуть, какие параметры передаются в DoSomethingUseful

Здравствуйте, igna, Вы писали:

I>На мой взгляд указание того, что URI является base address ничего не дает
Это дело привычки. Если ты привык к синтаксису 1 то вполне нормально. Мне же было сложно определить какой класс мы создаем (т.е. понадобилось искать, а не "кинуть взгляд" и понять).
I>зато объявление переменной заставляет смотреть, не используется ли она где-нибудь внутри using.
Так уж и заставляет

В общем, я за первый вариант.

Самое главное в любом подходе -- постоянство. Сами по себе оба подхода хороши (все зависит от привычек), но ни в коем случае не стоит их смешивать (часть вызовов так/часть так).

СУВ, Aikin

Здравствуйте, igna, Вы писали:

I>Совет минимизировать область видимости переменной общеизвестен. Минимальная область видимости это область видимости неименованной переменной, тем не менее часто избегают писать так:

Речь о шарпе? Тогда никакой разницы нет. Переменная становится доступной для сборщика мусора сразу после последнего использования.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, igna, Вы писали:

I>Совет минимизировать область видимости переменной общеизвестен. Минимальная область видимости это область видимости неименованной переменной, тем не менее часто избегают писать так:
...

Некоторая разница все же может быть:

* Порядок вычисления аргументов функции может быть не определен (зависит от языка, в С++ есть кое-какие грабли).

* Эквивалентность(точнее ее возможность) зависит от побочных эффектов функций:

    if (DoSomethingUseful(
        variable1.Method1(variable1A, variable1B),
        variable2.Method2(variable2A, variable2B),
        variable2.Method2(variable2A, variable2B)
    )) {
        . . .
    }
 
    var par1 = variable1.Method1(variable1A, variable1B);
    var par2 = variable2.Method2(variable2A, variable2B);
    if (DoSomethingUseful(par1, par2, par2)) {
        . . .
    }

Здравствуйте, Lloyd, Вы писали:

L>Речь о шарпе? Тогда никакой разницы нет. Переменная становится доступной для сборщика мусора сразу после последнего использования.

Речь об области видимости, а не о времени жизни. То есть думаем о человеке, читающем программу.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>    var par1 = variable1.Method1(variable1A, variable1B);
ЮЖ>    var par2 = variable2.Method2(variable2A, variable2B);
ЮЖ>    if (DoSomethingUseful(par1, par2, par2)) {
ЮЖ>        . . .
ЮЖ>    }

Я бы это кстати записал так:

    var par2 = variable2.Method2(variable2A, variable2B);
    if (DoSomethingUseful(variable1.Method1(variable1A, variable1B), par2, par2)) {
        . . .
    }

Даже если бы не "поместилось" в одной строке:

    var par2 = variable2.Method2(variable2A, variable2B);
    if (DoSomethingUseful(
        variable1.Method1(variable1A, variable1B),
        par2,
        par2
    )) {
        . . .
    }

Здравствуйте, igna, Вы писали:

L>>Речь о шарпе? Тогда никакой разницы нет. Переменная становится доступной для сборщика мусора сразу после последнего использования.

I>Речь об области видимости, а не о времени жизни. То есть думаем о человеке, читающем программу.

И в качестве средства заботы о человеке предлагаете инлайнить переменные?

Вы уверены, что читающий будет вам за это благодарен?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, igna, Вы писали:

I>Даже если бы не "поместилось" в одной строке:

I>

I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    if (DoSomethingUseful(
I>        variable1.Method1(variable1A, variable1B),
I>        par2,
I>        par2
I>    )) {
I>        . . .
I>    }
I>

Ужас какой!

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Lloyd, Вы писали:

L>Ужас какой!

Вариант:

    var par2 = variable2.Method2(variable2A, variable2B);
    if (
        DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            par2,
            par2
        )
    ) {
        . . .
    }

Здравствуйте, igna, Вы писали:

L>>Ужас какой!

I>Вариант:

I>

I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    if (
I>        DoSomethingUseful(
I>            variable1.Method1(variable1A, variable1B),
I>            par2,
I>            par2
I>        )
I>    ) {
I>        . . .
I>    }
I>

Ты прикалываешься или серьезно?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Lloyd, Вы писали:

L>Ты прикалываешься или серьезно?

Я пытаюсь сделать читабельнее обойдясь без введения переменной.

Вот еще вариант:

    var par2 = variable2.Method2(variable2A, variable2B);
    if (DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            par2,
            par2)
    ) {
        . . .
    }

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Юрий Жмеренецкий, Вы писали:

I>

ЮЖ>>    var par1 = variable1.Method1(variable1A, variable1B);
ЮЖ>>    var par2 = variable2.Method2(variable2A, variable2B);
ЮЖ>>    if (DoSomethingUseful(par1, par2, par2)) {
ЮЖ>>        . . .
ЮЖ>>    }
I>

I>Я бы это кстати записал так:

...

ЮЖ>> ... зависит от побочных эффектов функций
Я вот что имел ввиду:

int i = 0;

int f1() { return ++i; }

int f2(int a, int b) { return a+b; }

void test()
{
  // 1
  int a = f2(f1(), f1());

  // 2
  int b = f1();
  int c = f2(b, b);
    
  assert(a != c);
}

Здравствуйте, igna, Вы писали:

I>Я пытаюсь сделать читабельнее обойдясь без введения переменной.
А зачем?

Здравствуйте, igna, Вы писали:

L>>Ты прикалываешься или серьезно?

I>Я пытаюсь сделать читабельнее обойдясь без введения переменной.

Это самоцель? Зачем без переменной? В чем преимущество? Пока вроде только недостатки были найдены.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Aikin, Вы писали:

A>А зачем?

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

Здравствуйте, Lloyd, Вы писали:

L>Это самоцель? Зачем без переменной? В чем преимущество? Пока вроде только недостатки были найдены.

Ответил здесь.

Здравствуйте, igna, Вы писали:

L>>Это самоцель? Зачем без переменной? В чем преимущество? Пока вроде только недостатки были найдены.

I>Ответил здесь.

Ну так вот и ответь, зачем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Возможно лучше форматировать так:

    if (
        DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            variable2.Method2(variable2A, variable2B),
            variable3.Method3(variable3A, variable3B)
        )
    ) {
        . . .
    }

Здравствуйте, igna, Вы писали:

I>и пишут так:

I>

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>    }
I>

Это удобно при отладке. Ты видишь промежуточные значения без захода в функции.

Здравствуйте, igna, Вы писали:

I>Затем же, зачем рекомендуют минимизировать область видимости переменной.

Приведенный тобой пример это не минимизация области видимости переменной, которая имеет смыл только если переменная необходима. Ты решаешь вопрос — заводить переменную вообще или нет.

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

Так вот. Методика говорит — "не заводите переменных без надобности". Другая методика говорит — "код должен быть самодокументируемым".
Тут есть противоречие, ибо выделение переменной (скажем, в случае твоего примера) повышает самодокументируемость, но вводит ненужную перемернную.
Как понять — какой методике следовать? Это решает здравый смысл.

И объяснить тебе этого полностью с покрытием каждого варианта и частного случая я не могу.
Потому что если бы мог, то фиг бы я тебе это объяснил. Я в таком случае бы написал программу, которая преобразует поганый код в отличный, и заныкал бы ее себе . После чего разбогател бы, эксплуатируя толпы индусов и превращая их ХреноКод (tm) в Мега Шедевры (tm) и демонстрируя оные на выставках.

Здравствуйте, fmiracle, Вы писали:

F>Тут есть противоречие, ибо выделение переменной (скажем, в случае твоего примера) повышает самодокументируемость, но вводит ненужную перемернную.

Последнее всегда верно (к сожалению), а вот с самодокументируемостью дело обстоит так далеко не всегда. Какая самодокументируемость повышается, если результат возвращаемый методом CreateTransglucator() помещается в переменную transglucator? И когда видишь, что один и тот же человек пишет

    if (DoSomethingUseful(transglucatorFactory.CreateTransglucator())) {
        . . .
    }

, а в случае длинного списка параметров

    Transglucator transglucator = transglucatorFactory.CreateTransglucator();
    Glucatransor glucatransor = glucatransorFactory.CreateGlucatransor();
    AnotherShit anotherShit = anotherShitFactory.CreateAnotherShit();
    if (DoSomethingUseful(transglucator, glucatransor, anotherShit)) {
        . . .
    }

вместо

    if (
        DoSomethingUseful(
            transglucatorFactory.CreateTransglucator(),
            glucatransorFactory.CreateGlucatransor(),
            anotherShitFactory.CreateAnotherShit()
        )
    ) {
        . . . 
    }

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

Здравствуйте, VladD2, Вы писали:

VD>Это удобно при отладке. Ты видишь промежуточные значения без захода в функции.

Вот такое тоже удобно при отладке:

    var par1 = variable1.Method1(variable1A, variable1B);
    if (DoSomethingUseful(par1)) {
        . . .
    }

Но чаще пишут все же:

    if (DoSomethingUseful(variable1.Method1(variable1A, variable1B)) {
        . . .
    }

А как только появляются длинные списки параметров, появляются и промежуточные переменные, лишь бы всунуть соответствующие круглые скобки в одну строку. Хотя честно говоря непонятно, чем круглые скобки "хуже" фигурных.

Здравствуйте, Lloyd, Вы писали:

L>Ну так вот и ответь, зачем.

Это просто, она мешается. Например возникает необходимость добавить еще один вызов DoSomethingUseful внутри брока if:

    var par1 = variable1.Method1(variable1A, variable1B);
    var par2 = variable2.Method2(variable2A, variable2B);
    var par3 = variable3.Method3(variable3A, variable3B);
    if (DoSomethingUseful(par1, par2, par3)) {
        . . .
        var par1a = variable1.Method1(variable1A, variable1B);
        var par2a = variable2.Method2(variable2A, variable2B);
        var par3a = variable3.Method3(variable3A, variable3B);
        if (DoSomethingUseful(par1a, par2a, par3)) {
            . . .
        }
        . . .
    }

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

А ведь все было так просто:

    if (
        DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            variable2.Method2(variable2A, variable2B),
            variable3.Method3(variable3A, variable3B)
        )
    ) {
        . . .
        if (
            DoSomethingUseful(
                variable1.Method1(variable1A, variable1B),
                variable2.Method2(variable2A, variable2B),
                variable3.Method3(variable3A, variable3B)
            )
        ) {
            . . .
        }
        . . .
    }

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Я вот что имел ввиду:

Да, спасибо, я понял. Просто не упустил случая показать, как написал бы в этом случае сам.

Здравствуйте, igna, Вы писали:

I>

I>    Transglucator transglucator = transglucatorFactory.CreateTransglucator();
I>    Glucatransor glucatransor = glucatransorFactory.CreateGlucatransor();
I>    AnotherShit anotherShit = anotherShitFactory.CreateAnotherShit();
I>    if (DoSomethingUseful(transglucator, glucatransor, anotherShit)) {
I>        . . .
I>    }
I>

I>, то думаешь, что его пугает синтаксис со вложенными скобками. А программа нисколько не становится понятнее, от того что в ней слово transglucator упоминается четыре раза вместо одного.

Фабрика трансглюкаторов что-то умеет создавать кроме трансглюкаторов?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Lloyd, Вы писали:

L>>Ну так вот и ответь, зачем.

I>Это просто, она мешается. Например возникает необходимость добавить еще один вызов DoSomethingUseful внутри брока if:
...

I>А ведь все было так просто:

I>

I>    if (
I>        DoSomethingUseful(
I>            variable1.Method1(variable1A, variable1B),
I>            variable2.Method2(variable2A, variable2B),
I>            variable3.Method3(variable3A, variable3B)
I>        )
I>    ) {
I>        . . .
I>        if (
I>            DoSomethingUseful(
I>                variable1.Method1(variable1A, variable1B),
I>                variable2.Method2(variable2A, variable2B),
I>                variable3.Method3(variable3A, variable3B)
I>            )
I>        ) {
I>            . . .
I>        }
I>        . . .
I>    }
I>

Это просто? За такое дублирование отстреливают. ExtractMethod!!!

Я в прошлом проекте видел как люди делают так:

    {
        var par1 = variable1.Method1(variable1A, variable1B);
        var par2 = variable2.Method2(variable2A, variable2B);
        var par3 = variable3.Method3(variable3A, variable3B);
        if (DoSomethingUseful(par1, par2, par3)) {
            . . .
        }
    }

Здравствуйте, samius, Вы писали:

S>Здравствуйте, igna, Вы писали:

I>>А ведь все было так просто:
[]

S>Это просто? За такое дублирование отстреливают. ExtractMethod!!!

А чтобы не плодить 6 параметров, можно обойтись лямбдой

Здравствуйте, samius, Вы писали:

S>Фабрика трансглюкаторов что-то умеет создавать кроме трансглюкаторов?

Не придирайся, мне просто нужно было длинное имя.

Здравствуйте, samius, Вы писали:

S>Это просто? За такое дублирование отстреливают. ExtractMethod!!!

Ты опять придираешься. Речь не о том, а о том, что вместо например:

    var par1 = variable1.Method1(variable1A, variable1B);
    var par2 = variable2.Method2(variable2A, variable2B);
    var par3 = variable3.Method3(variable3A, variable3B);
    if (DoSomethingUseful(par1, par2, par3)) {
        . . .
        var par1a = callSomeFunctionWithALongName1();
        var par2a = callSomeFunctionWithALongName2();
        var par3a = callSomeFunctionWithALongName3();
        if (DoSomethingUseful(par1a, par2a, par3a)) {
            . . .
        }
        . . .
    }

ошибкоустойчивее использовать

    if (
        DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            variable2.Method2(variable2A, variable2B),
            variable3.Method3(variable3A, variable3B)
        )
    ) {
        . . .
        if (
            DoSomethingUseful(
                callSomeFunctionWithALongName1(),
                callSomeFunctionWithALongName2(),
                callSomeFunctionWithALongName3()
            )
        ) {
            . . .
        }
        . . .
    }

По поводу твоих придирок: Даже в книгах, за которые авторы деньги получают, в примерах весьма нередко можно найти какие-либо не относящиеся к рассматриваемому вопросу недочеты. Уж для упрощения ли или от авторской лени ... А я и вовсе не пытаюсь ничего продавать, так что не обессудь, мои примеры для людей обладающих способностью мыслить абстрактно.

Здравствуйте, yumi, Вы писали:

Y>Я в прошлом проекте видел как люди делают так:
Y>

Y>    {
Y>        var par1 = variable1.Method1(variable1A, variable1B);
Y>        var par2 = variable2.Method2(variable2A, variable2B);
Y>        var par3 = variable3.Method3(variable3A, variable3B);
Y>        if (DoSomethingUseful(par1, par2, par3)) {
Y>            . . .
Y>        }
Y>    }
Y>

IMHO это лучше, чем без внешних фигурных скобок, но внутри блока if переменные все же видны.

Здравствуйте, Aikin, Вы писали:

A>А зачем?

Ответил здесь.

Здравствуйте, igna, Вы писали:

L>>Ну так вот и ответь, зачем.

I>Это просто, она мешается. Например возникает необходимость добавить еще один вызов DoSomethingUseful внутри брока if:

Бредовый какой-то аргумент. Давай нормальные имена и ничего не будет мешаться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, igna, Вы писали:

I>Компилируем, запускаем программу, некоторое время работаем с ней. Вроде все нормально, но что-то не так. Через пару часов обнаруживаем, что во втором вызове по ошибке использован параметр первого.
I>А ведь все было так просто:
igna, ты сам себе придумываешь проблемы, а потом их с успехом решаешь.

P.S. Я еще раз настоятельно прошу писать примеры с осмысленными именами! Потому как совсем не видно как будет выглядеть код написанный по твоему подходу. Вполне возможно вопросы отпадут сами собой.

Здравствуйте, igna, Вы писали:

VD>>Это удобно при отладке. Ты видишь промежуточные значения без захода в функции.

I>Вот такое тоже удобно при отладке:

I>

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    if (DoSomethingUseful(par1)) {
I>        . . .
I>    }
I>

I>Но чаще пишут все же:

Чаще как раз пишут с заведением промежуточных переменных.
В общем, кури Рефакторинг Фаулера. Там есть объяснения многого из того, как делать не стоит. Про временные переменные там вроде тоже было. Только не помню, за них или против.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, igna, Вы писали:

I>IMHO это лучше, чем без внешних фигурных скобок,

ИМХО, только хуже.

I>но внутри блока if переменные все же видны.

Ну и замечательно. Удобно же.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Lloyd, Вы писали:

L>В общем, кури Рефакторинг Фаулера. Там есть объяснения многого из того, как делать не стоит. Про временные переменные там вроде тоже было. Только не помню, за них или против.

Он написал, что "за", только если они являются поясняющими, но сам использует их редко.

Здравствуйте, Lloyd, Вы писали:

L>Ну и замечательно. Удобно же.

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

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>    }
I>

Хм... А я почему-то всегда стараюсь чтобы в условиях циклов и условных операторов не было (по возможности) вызовов функций. То есть этот участок я бы переписал как

  {
    int par1 = var1.m1(v1a, v1b);
    int par2 = var2.m1(v2a, v2b);
    int par3 = var3.m1(v3a, v3b);
    bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
    if (boSomethingUsefulOk){
      // ...
    }
  }

И мне кажется любому читающему так гораздо понятней -- мы вводим дополнительную сущность, которая имеет смысл "всё ли в порядке". Представьте что пройдёт какое-то время и вам придётся в if заходить если DoSomethingUseful и при это DoSomethingUseful2. Тогда ваш вариант предполагает следующее расширение:

if (DoSomethingUseful(par1, par2, par3) && DoSomethingUseful2(par1, par2, par3)) {

а мой вариант остаётся читабельным:

bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
bool boSomethingUseful2Ok = DoSomethingUseful2(par1, par2, par3);
if (boSomethingUsefulOk && boSomethingUseful2Ok) {
...
}

не говоря уже о том, что вариант с внесением всего что можно в скобки условия порождает такие варианты как

for (int i = 0; i != lstrlenA(str); ++i){
  //...
}

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

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

Здравствуйте, igna, Вы писали:

L>>Ну и замечательно. Удобно же.

I>Ну да, как удобны грабли. В смысле, всегда есть на что наступить.

В реале, если давать осмысленные имена, не возникает такой проблемы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Это просто? За такое дублирование отстреливают. ExtractMethod!!!

I>Ты опять придираешься. Речь не о том, а о том, что вместо например:

I>

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>        var par1a = callSomeFunctionWithALongName1();
I>        var par2a = callSomeFunctionWithALongName2();
I>        var par3a = callSomeFunctionWithALongName3();
I>        if (DoSomethingUseful(par1a, par2a, par3a)) {
I>            . . .
I>        }
I>        . . .
I>    }
I>

I>ошибкоустойчивее использовать

I>

I>    if (
I>        DoSomethingUseful(
I>            variable1.Method1(variable1A, variable1B),
I>            variable2.Method2(variable2A, variable2B),
I>            variable3.Method3(variable3A, variable3B)
I>        )
I>    ) {
I>        . . .
I>        if (
I>            DoSomethingUseful(
I>                callSomeFunctionWithALongName1(),
I>                callSomeFunctionWithALongName2(),
I>                callSomeFunctionWithALongName3()
I>            )
I>        ) {
I>            . . .
I>        }
I>        . . .
I>    }
I>

А так:

    Func<bool> doSomething = () =>
       DoSomethingUseful(
            variable1.Method1(variable1A, variable1B),
            variable2.Method2(variable2A, variable2B),
            variable3.Method3(variable3A, variable3B)

    if (doSomething())
    {
        . . .
        if (doSomething())
        {
            . . .
        }
        . . .
    }

I>По поводу твоих придирок: Даже в книгах, за которые авторы деньги получают, в примерах весьма нередко можно найти какие-либо не относящиеся к рассматриваемому вопросу недочеты. Уж для упрощения ли или от авторской лени ... А я и вовсе не пытаюсь ничего продавать, так что не обессудь, мои примеры для людей обладающих способностью мыслить абстрактно.

Ну тогда извини

Здравствуйте, Tilir, Вы писали:

T>    bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
T>    if (boSomethingUsefulOk){
T>      // ...
T>    }
T>  }

А так не пробовал?:

    bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
    if (boSomethingUsefulOk == true){
      // ...
    }
  }

Здравствуйте, igna, Вы писали:

I>А так не пробовал?:

I>

I>    bool boSomethingUsefulOk = DoSomethingUseful(par1, par2, par3);
I>    if (boSomethingUsefulOk == true){
I>      // ...
I>    }
I>  }
I>

У меня есть замечательная привычка в таких сравнениях писать константу до (чтобы не нарваться на присваивание):

    int iSomethingUsefulResult = DoSomethingUseful(par1, par2, par3);
    if (0 == iSomethingUsefulResult){
      // ...
    }
  }

Но делать такое в случае булевских переменных мне кажется избыточно. Аналогично в случае указателей. И там и там вобщемт всего два логических варианта -- TRUE/FALSE, либо NULL/NOT NULL и в обоих случаях if (pString) и соответственно if (!boFailed) вполне читабельны. Впрочем дело вкуса и ничего религиозного -- при соответствующих code guidelines я был бы согласен легко перестроится на явное сравнение.

I>    var par1 = variable1.Method1(variable1A, variable1B);
I>    var par2 = variable2.Method2(variable2A, variable2B);
I>    var par3 = variable3.Method3(variable3A, variable3B);
I>    if (DoSomethingUseful(par1, par2, par3)) {
I>        . . .
I>    }
I>

А я пишу так:

  var par1 = variable1.Method1(variable1A, variable1B);
  {
    var par2 = variable2.Method2(variable2A, variable2B);
    var par3 = variable3.Method3(variable3A, variable3B);
    if (DoSomethingUseful(par1, par2, par3)) {
        . . .
    }
  }
  
  DoSomethingAnotherUseful(par1);

И область видимости минимизируется, и отлаживать удобно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Andrei F., Вы писали:

AF>А я пишу так:

AF>  var par1 = variable1.Method1(variable1A, variable1B);
AF>  {
AF>    var par2 = variable2.Method2(variable2A, variable2B);
AF>    var par3 = variable3.Method3(variable3A, variable3B);
AF>    if (DoSomethingUseful(par1, par2, par3)) {
AF>        . . .
AF>    }
AF>  }
  
AF>  DoSomethingAnotherUseful(par1);

AF>И область видимости минимизируется, и отлаживать удобно.

Я тоже так пишу, если par2 и par3 используются в теле блока if.

	От:	igna
	Дата:	29.10.08 11:47
	Оценка:	+2

От:	Aikin	kavaleu.ru
Дата:	29.10.08 11:50
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	29.10.08 11:51
Оценка:

	От:	igna
	Дата:	29.10.08 11:57
	Оценка:

От:	Aikin	kavaleu.ru
Дата:	29.10.08 12:02
Оценка:

От:	Юрий Жмеренецкий	ICQ 380412032
Дата:	29.10.08 13:05
Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	29.10.08 15:57
Оценка:	+1

От:	Tilir	http://tilir.livejournal.com
Дата:	30.10.08 09:05
Оценка:	-1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	30.10.08 22:39
Оценка: