Проверка условий и "ширина" кода
От: AlexKr  
Дата: 28.04.08 07:38
Оценка: +4
Добрый день.

Только мне не нравится этот код или это тайный заговор — делать код "шире"? Я постоянно встречаю такой код. Пишут так и новички и люди, чей стаж больше моего. Причем уровень вложенности часто доходит до 6-8. Здесь не обсуждается вариант с else.

bool func1()
{
    if( condition1 )
    {
        do1();

        if( condition2 )
        {
            do2();

            if( condition3 )
            {
                do3();

                if( condition4 )
                {
                    do4();

                    return true;
                }
            }
        }
    }

    return false;
}


Конечно, он читаемый, но, почему бы не писать так:

bool func1()
{
    if( !condition1 )
        return false;

    do1();

    if( !condition2 )
        return false;

    do2();

    if( !condition3 )
        return false;

    do3();

    if( !condition4 )
        return false;

    do4();

    return true;
}
Re: Проверка условий и "ширина" кода
От: jazzer Россия Skype: enerjazzer
Дата: 28.04.08 07:46
Оценка: 24 (1) +5
Здравствуйте, AlexKr, Вы писали:

AK>Добрый день.

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"? Я постоянно встречаю такой код. Пишут так и новички и люди, чей стаж больше моего. Причем уровень вложенности часто доходит до 6-8. Здесь не обсуждается вариант с else.

Это — давнее суеверие, что в функции должно быть только одно место для выхода (single return).

Оно частично имеет смысл для С (освобождение ресурсов перед выходом), но для С++, очевидно, оно абсурдно, потому что исключение может вылететь практически из любой строчки.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Проверка условий и "ширина" кода
От: andrey.desman  
Дата: 28.04.08 08:14
Оценка:
Здравствуйте, AlexKr, Вы писали:



bool func1
{
    return condition1 && (do1(), true) &&
           condition2 && (do2(), true) && 
           condition3 && (do3(), true) &&
           condition4 && (do4(), true);
}
Re: Проверка условий и "ширина" кода
От: Константин Л. Франция  
Дата: 28.04.08 08:37
Оценка: +1
Здравствуйте, AlexKr, Вы писали:

AK>Добрый день.

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"? Я постоянно встречаю такой код. Пишут так и новички и люди, чей стаж больше моего. Причем уровень вложенности часто доходит до 6-8. Здесь не обсуждается вариант с else.

не только тебе. предпочитаю 2-ой вариант

[]
Re: Проверка условий и "ширина" кода
От: C0s Россия  
Дата: 28.04.08 08:52
Оценка: +1
Здравствуйте, AlexKr, Вы писали:

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"?

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

AK>Я постоянно встречаю такой код

могу только посочувствовать
Re: Проверка условий и "ширина" кода
От: Roman Odaisky Украина  
Дата: 28.04.08 09:42
Оценка: +1
Здравствуйте, AlexKr, Вы писали:

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"?

Flat is better than nested.

http://www.python.org/dev/peps/pep-0020/

Однако «широкий» вариант имеет то преимущество, что там можно аккуратнее управлять видимостью и временем жизни переменных:
if(X x = getX())
{
    do1();
    if(Y y = getY())
    {
        do2();
    }
    // здесь y.~Y()
    do3();
}
До последнего не верил в пирамиду Лебедева.
Re[2]: Проверка условий и "ширина" кода
От: AlexKr  
Дата: 28.04.08 09:55
Оценка:
...Вместо do() может быть несколько строк кода.
Re[2]: Проверка условий и "ширина" кода
От: AlexKr  
Дата: 28.04.08 09:59
Оценка: +1
Да, пару раз спорил, помню такой аргумент. Но мой вывод, что такой код в 95% случаев пишется без аргумента, просто так.
Re[2]: Проверка условий и "ширина" кода
От: CreatorCray  
Дата: 28.04.08 10:52
Оценка: 1 (1) +4 -2
Здравствуйте, andrey.desman, Вы писали:

AD>
AD>bool func1
AD>{
AD>    return condition1 && (do1(), true) &&
AD>           condition2 && (do2(), true) && 
AD>           condition3 && (do3(), true) &&
AD>           condition4 && (do4(), true);
AD>}
AD>

Читабельность еще хуже чем у первых двух ИМХО
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Проверка условий и "ширина" кода
От: jazzer Россия Skype: enerjazzer
Дата: 28.04.08 12:11
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Однако «широкий» вариант имеет то преимущество, что там можно аккуратнее управлять видимостью и временем жизни переменных:
RO>
RO>if(X x = getX())
RO>{
RO>    do1();
RO>    if(Y y = getY())
RO>    {
RO>        do2();
RO>    }
RO>    // здесь y.~Y()
RO>    do3();
RO>}
RO>


твой код не эквивалентен обсуждаемому
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: Проверка условий и "ширина" кода
От: Кодт Россия  
Дата: 28.04.08 15:05
Оценка: +2
Здравствуйте, andrey.desman, Вы писали:

AD>
AD>bool func1
AD>{
AD>    return condition1 && (do1(), true) &&
AD>           condition2 && (do2(), true) && 
AD>           condition3 && (do3(), true) &&
AD>           condition4 && (do4(), true);
AD>}
AD>

А теперь попробуйте в отладчике, по шагам...
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re: Проверка условий и "ширина" кода
От: licedey  
Дата: 28.04.08 15:20
Оценка: :))) :)))
Здравствуйте, AlexKr, Вы писали:

AK>Добрый день.

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"? Я постоянно встречаю такой код. Пишут так и новички и люди, чей стаж больше моего. Причем уровень вложенности часто доходит до 6-8. Здесь не обсуждается вариант с else.

Это дело привычки. Сам стараюсь писать код так, чтобы не приходилось пользоваться горизонтальным скрол баром.
Хотя с другой стороны, сейчас работаю над проектом, в котором используется MSHTML. Так приходится себя заставлять
писать вложенные if'ы, до 20 штук доходит. А все потому, что при получении интерфейса на любой элемент, нужно вызывать Release после использования. Напрягает жутко. Иногда просто забиваю на все релизы, отчего memory leaks бывают до 1GB при определенных условиях . Вот она цена привычки. Странно, что клиент закрывает на это глаза.

Правильно так:
if( SUCCEEDED( ob1->QueryInterface( &i1 ) ) )
{
  if( SUCCEEDED( i1->QueryInterface( &i2 ) ) )
  {
    // далее порядка еще 10 подобных вызовов
    ...
    i2->Release();
  }
  i1->Release();
}


По привычке часто пишу так:
if( FAILED( ob1->QueryInterface( &i1 ) ) )
  return;
if( FAILED( i1->QueryInterface( &i2 ) ) )
  return;
Re[2]: Проверка условий и "ширина" кода
От: Константин Л. Франция  
Дата: 28.04.08 15:46
Оценка: 1 (1) +5
Здравствуйте, licedey, Вы писали:

[]

L>Это дело привычки. Сам стараюсь писать код так, чтобы не приходилось пользоваться горизонтальным скрол баром.
L>Хотя с другой стороны, сейчас работаю над проектом, в котором используется MSHTML. Так приходится себя заставлять
L>писать вложенные if'ы, до 20 штук доходит. А все потому, что при получении интерфейса на любой элемент, нужно вызывать Release после использования. Напрягает жутко. Иногда просто забиваю на все релизы, отчего memory leaks бывают до 1GB при определенных условиях . Вот она цена привычки. Странно, что клиент закрывает на это глаза.

странно, что ты закрываешь на это глаза

открой для себя мир smart pointers (hint: ATL::CComPtr, _com_ptr_t, boost::intrusive_ptr)

[]
Re: Проверка условий и "ширина" кода
От: Miroff Россия  
Дата: 29.04.08 08:25
Оценка:
Здравствуйте, AlexKr, Вы писали:

AK>Только мне не нравится этот код или это тайный заговор — делать код "шире"? Я постоянно встречаю такой код. Пишут так и новички и люди, чей стаж больше моего. Причем уровень вложенности часто доходит до 6-8. Здесь не обсуждается вариант с else.

У меня такой код часто получается в результате автоматической генерации из таблицы решений. Заниматься ручной оптимизацией, конечно, можно, но влом.
Re[2]: Проверка условий и "ширина" кода
От: Erop Россия  
Дата: 29.04.08 09:59
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Однако «широкий» вариант имеет то преимущество, что там можно аккуратнее управлять видимостью и временем жизни переменных:
А в "узком" не судьба, что ли do7 в отдельный блоок затолкать, если оно надо?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Проверка условий и "ширина" кода
От: licedey  
Дата: 30.04.08 12:53
Оценка: :))
Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, licedey, Вы писали:

КЛ>[]

L>>Это дело привычки. Сам стараюсь писать код так, чтобы не приходилось пользоваться горизонтальным скрол баром.
L>>Хотя с другой стороны, сейчас работаю над проектом, в котором используется MSHTML. Так приходится себя заставлять
L>>писать вложенные if'ы, до 20 штук доходит. А все потому, что при получении интерфейса на любой элемент, нужно вызывать Release после использования. Напрягает жутко. Иногда просто забиваю на все релизы, отчего memory leaks бывают до 1GB при определенных условиях . Вот она цена привычки. Странно, что клиент закрывает на это глаза.

КЛ> странно, что ты закрываешь на это глаза

КЛ>открой для себя мир smart pointers (hint: ATL::CComPtr, _com_ptr_t, boost::intrusive_ptr)

КЛ>[]

Когда проект только начинался, я за основу взял исходники где не используются смарты.
Я в таком же стиле стал писать, но не курсе был что нужно release вызывать. Догнал только
когда обнаружил что память безвозвратно теряется . Тогда стал лепить CComPtr в старый код,
отчего тот стал падать. Думаю теперь через макросы решить проблему...
Типа:
#define R3(a,b,c) (a->Release(),b->Release(),c->Release())
Re[3]: Проверка условий и "ширина" кода
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.08 17:55
Оценка:
Здравствуйте, Кодт, Вы писали:

AD>>
AD>>bool func1
AD>>{
AD>>    return condition1 && (do1(), true) &&
AD>>           condition2 && (do2(), true) && 
AD>>           condition3 && (do3(), true) &&
AD>>           condition4 && (do4(), true);
AD>>}
AD>>

К>А теперь попробуйте в отладчике, по шагам...

Это проблемы компилятора/отладчика. В том же Немерле мы по такому коду "ходим" на раз. Спасибо IT!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Проверка условий и "ширина" кода
От: Left2 Украина  
Дата: 30.04.08 18:57
Оценка:
L>Думаю теперь через макросы решить проблему...
L>Типа:
L>#define R3(a,b,c) (a->Release(),b->Release(),c->Release())
сдаётся мне что за такое решение коллеги которые будут потом сопровождать твой код оторвут тебе чего-нить.
Так что никаких макросов, юзай правильно смартпоинтеры и ничего падать не будет.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[4]: Проверка условий и "ширина" кода
От: Кодт Россия  
Дата: 30.04.08 19:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это проблемы компилятора/отладчика. В том же Немерле мы по такому коду "ходим" на раз. Спасибо IT!

А в VB это ещё в 6 версии было. (А может, и в 5, не помню).
Проблемы в том, что в С/С++ с давних (наверное, с фортрановских) времён принято точки расставлять по строкам.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[4]: Проверка условий и "ширина" кода
От: Кодт Россия  
Дата: 30.04.08 19:08
Оценка:
Здравствуйте, licedey, Вы писали:

L>Когда проект только начинался, я за основу взял исходники где не используются смарты.
L>Я в таком же стиле стал писать, но не курсе был что нужно release вызывать. Догнал только
L>когда обнаружил что память безвозвратно теряется . Тогда стал лепить CComPtr в старый код,
L>отчего тот стал падать. Думаю теперь через макросы решить проблему...
L>Типа:
L>#define R3(a,b,c) (a->Release(),b->Release(),c->Release())

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

Лепить желательно не CComPtr, потому что у него есть неявное приведение к голому указателю. Будет мало крови при компиляции.

Находишь все QueryInterface, Release и переделываешь тип найденных рядом переменных на умные указатели. И убираешь Release.
Переделываешь сигнатуры функций (кроме интерфейсных, увы), чтоб они принимали только умные указатели.
Переделываешь все структуры и классы, чтоб их члены были умными.

Можно пойти таким путём: искать все вхождения Iblablabla* и заменять на intrusive_ptr<Iblablabla>.
А там, где голые указатели почему-то нужны — там, увы, восстанавливаешь.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.