Re[5]: Проверка условий и "ширина" кода
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.08 19:19
Оценка: +2
Здравствуйте, Кодт, Вы писали:

К>Проблемы в том, что в С/С++ с давних (наверное, с фортрановских) времён принято точки расставлять по строкам.

Еще надо добавить "Майкрософтом".

Почему-то для С++ многое довольно не удобно. Но это ведь не значит, что сам подход плох?

Лично мне проще читать код более компактный. Ну, зачем мне искать логику по странице если ее можно собрать водном месте?

Почему-то те кто программируют на императивных языках (особенно на С-подобных) частенько плюют на понятность кода в угоду, скажем, отладке (или еще чему-то). Но ведь более понятный и краткий код сам по себе снижает необходимость в отладке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Проверка условий и "ширина" кода
От: Кодт Россия  
Дата: 03.05.08 23:13
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Почему-то для С++ многое довольно не удобно. Но это ведь не значит, что сам подход плох?

— Понимаешь, сынок, есть такое слово "Родина"

VD>Лично мне проще читать код более компактный. Ну, зачем мне искать логику по странице если ее можно собрать водном месте?

VD>Почему-то те кто программируют на императивных языках (особенно на С-подобных) частенько плюют на понятность кода в угоду, скажем, отладке (или еще чему-то). Но ведь более понятный и краткий код сам по себе снижает необходимость в отладке.

Чисто для флейма могу предположить, что мега-конъюнкция или мега-дизъюнкция не повышает читаемость.
Потому что в ней одновременно закодированы две вещи
— булево выражение (в том числе, обладает коммутативностью)
— последовательность выражений (некоммутативность)
И с разбегу сказать, важна ли здесь последовательность (обеспечивающая предусловие, или хотя бы оптимизирующая вычисление сложных выражений — когда менее вероятные предикаты ставятся в начале) — это вопрос.
Перекуём баги на фичи!
Re[7]: Проверка условий и "ширина" кода
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.08 08:51
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Чисто для флейма могу предположить, что мега-конъюнкция или мега-дизъюнкция не повышает читаемость.
К>Потому что в ней одновременно закодированы две вещи
К>- булево выражение (в том числе, обладает коммутативностью)
К>- последовательность выражений (некоммутативность)
К>И с разбегу сказать, важна ли здесь последовательность (обеспечивающая предусловие, или хотя бы оптимизирующая вычисление сложных выражений — когда менее вероятные предикаты ставятся в начале) — это вопрос.

Странная логика. А последовательность ифов (гора, точнее сказать) лучше передает суть?

Тут скорее в другую сторону надо посмотреть. Ведь все эти проверки чего-то означают. Не так ли?
А раз так, то логично было бы разнести их на отдельные функции с разумными именами. Тогда код бы стал понятнее, и что самое забавное, еще короче!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Проверка условий и "ширина" кода
От: _Jane_ Украина  
Дата: 05.06.08 08:44
Оценка: 2 (1) +2
Здравствуйте, AlexKr, Вы писали:

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

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

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

AK>        if( condition2 )
AK>        {
AK>            do2();

AK>            if( condition3 )
AK>            {
AK>                do3();

AK>                if( condition4 )
AK>                {
AK>                    do4();

AK>                    return true;
AK>                }
AK>            }
AK>        }
AK>    }

AK>    return false;
AK>}
AK>


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

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

AK>    do1();

AK>    if( !condition2 )
AK>        return false;

AK>    do2();

AK>    if( !condition3 )
AK>        return false;

AK>    do3();

AK>    if( !condition4 )
AK>        return false;

AK>    do4();

AK>    return true;
AK>}
AK>
Jane
Re: Проверка условий и "ширина" кода
От: Tesh США  
Дата: 11.06.08 20:09
Оценка:
Здравствуйте, AlexKr, Вы писали:

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

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

[Skipped]

вместо 
    if ( condition1 )
        return false;

предпочитаю писать
    if ( condition1 )
    {
        return false;
    }


т.к. второй вариант позволяет избежать возможной ошибки, когда другой девелопер решит исправить этот код, добавив например do(); таким образом:
    if ( condition1 )
        do();
        return false;

а так получится со вторым вариантом
    if ( condition1 )
    {
        do();
        return false;
    }

да и смотрится лучше, другое дело что вложенностей таких какие описаны у вас — не бывает
+есть такое понятие как корпоративный стандарт оформления кода
... << RSDN@Home 1.2.0 alpha 4 rev. 1090>>
Re[2]: Проверка условий и "ширина" кода
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 17.06.08 06:35
Оценка:
Здравствуйте, licedey, Вы писали:

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

Если тебе недоступны ни smart pointers, ни другой аналогичный подход — тогда вспомни про goto:

  Object *p1 = NULL, *p2 = NULL, *p3 = NULL, *p4 = NULL; // и так далее
  int rc = 0;
  //...
  if (FAILED(action1)) { rc = ERROR_BUKA; goto Cleanup; }
  // ...
  if (FAILED(action2)) { rc = ERROR_ZUKA; goto Cleanup; }
  // ура! получилось!
  rc = SUCCESS;
Cleanup:
  if (p1) Object_delete(p1);
  if (p2) Object_delete(p2);
  if (p3) Object_delete(p3);
  if (p4) Object_delete(p4);
  return rc;
}


Были у меня разработки, где можно было писать только так... никакого C++ и прочих "высоких" средств не допускалось. Но проблем это не составляло — после того, как метод построения кода специфицирован вплоть до имени метки, объяснён и понят, споров вокруг идеологии и реализации уже не было.

L>По привычке часто пишу так:
L>
L>if( FAILED( ob1->QueryInterface( &i1 ) ) )
L>  return;
L>if( FAILED( i1->QueryInterface( &i2 ) ) )
L>  return;
L>


Ну вот и перепиши на любой доступный, но не оставляющий ликов, вариант :)
The God is real, unless declared integer.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.