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

В качестве примера, только недавно столкнулся с таким: тело функции обёрнутов try, в середине выполнения стоит return. Код падал в finally, стектрейс был без номеров строк. И просматривая код сразу было непонято, как вообще выполнение туда добралось. Конечно, потом проблему нашли. Но время было потрачено...

Моё любимое правило: код пишется не для машины, он пишется для человека, который будет потом его читать

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Можно пример "чистоты"?

ТЗИ>Чем

ТЗИ>

ТЗИ>Result result = SomeFunction();
ТЗИ>if (result == Result.Error)
ТЗИ>{
ТЗИ>    ... 
ТЗИ>}
ТЗИ>

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

ТЗИ>принципиально отличается от

ТЗИ>

ТЗИ>    SomeFunction()
ТЗИ>

ТЗИ>?

Я поправил. try catch не надо писать на каждую функцию и это самое главное преимущество.

try-catch будет где нибдь выше по стеку, где угодно.

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

TA>Вопрос:
TA>Специалист А утверждал — выход из фунуций по середине кода затурдняют чтение кода и ее проверки, и поэтому надо запретить такой подход.
TA>Специалист Б утверждал — часто функция распознает когда не стоит продолжать выполнение и лучше выйти сразу, в противном случае код получается запутанным.
TA>В качесте компромисса, было решено разрешать функциям выход только в двух моментах: сразу в начале, а если нет, то в конце.
TA>Надо подумать как можно реализовать это предложение. И какой синтаксис можно предложить.

Дык все давно придумано за вас. Используйте любой ФЯ и будет вам щастье.

Например, для Nemerle ваша компромиссное правило выполняется автоматом почти всеми кто пишет на этом языке. Происходит это потому, что конструкции вроде return, breack и continue в нем макросы которые еще специальным образом нужно "открыть" (с помощью директвы using).

Примером может служить практически любой код на Nemerle

TA>Я не очень понял в чем вопрос, т.к., по моему ответ в самом вопросе. Надо проверить в начале, а если нет, то в конце. Или я что-то не так понял???
TA>Буду рад лубому решению.

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

I>Я поправил. try catch не надо писать на каждую функцию и это самое главное преимущество.
I>try-catch будет где нибдь выше по стеку, где угодно.

Идею я понял. Но что-то не могу придумать пример. Так ли уж много ситуаций, когда можно давать исключению свободно пролетать на уровень выше? Вообще, хорошая ли это практика не обрабатывать исключения, а давать им пролетать? Не будет ли такая практика вести к ошибкам? Ладно Java, например, заставляет помнить об исключениях, а в C++ про них можно просто забыть на более высоком уровне. Еще же может быть, что на более высоких уровнях уже пропадает контекст, в котором исключение имеет смысл обрабатывать.

Не знаю, на практике я просто вижу, что портянка if'ов заменяется на портянку try/catch'ей, которые тоже, на мой взгляд, красотой не блещут.

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

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

S>Вот собственно есть что сравнить (нарочно не стал использовать тройственный оператор). Для достижения единственности точки выхода пришлось ввести изменяемое состояние и увеличить вложенность ветвления. То ли еще будет, когда придется столкнуться с вложенными циклами. Там наверняка придется вводить флаги. ИМХО, в читаемости мы потеряли.

Увеличивать вложенность-то зачем?

    if( a < b )
        result = -1;
    else if( a > b )
        result = 1;
    else
        result = 0;

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

Pzz>Увеличивать вложенность-то зачем?
Pzz>

Pzz>    if( a < b )
Pzz>        result = -1;
Pzz>    else if( a > b )
Pzz>        result = 1;
Pzz>    else
Pzz>        result = 0;
Pzz>

Второй if разве не вложен в ветку else первого? Второй else разве того же уровня что и первый? Имхо, это несколько обманчивый способ форматирования. На самом деле здесь лесенка.

Здравствуйте, Тролль зеленый и толстый, Вы писали:

I>>Я поправил. try catch не надо писать на каждую функцию и это самое главное преимущество.
I>>try-catch будет где нибдь выше по стеку, где угодно.

ТЗИ>Идею я понял. Но что-то не могу придумать пример. Так ли уж много ситуаций, когда можно давать исключению свободно пролетать на уровень выше? Вообще, хорошая ли это практика не обрабатывать исключения, а давать им пролетать?

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

>Еще же может быть, что на более высоких уровнях уже пропадает контекст, в котором исключение имеет смысл обрабатывать.

ТЗИ>Не знаю, на практике я просто вижу, что портянка if'ов заменяется на портянку try/catch'ей, которые тоже, на мой взгляд, красотой не блещут.

Если портянка на портянку, то где то ошибки в дизайне. Конечно же портянка ифов лучше портянки трай-кетч

ТЗИ>Так получилось, что я до сих пор писал код для мобильных платформ, где исключения вообще не использовались. Так что я в них не силен и хочу понять.

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

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

TA>выход из фунуций по середине кода затурдняют чтение кода и ее проверки, и поэтому надо запретить такой подход.
TA>часто функция распознает когда не стоит продолжать выполнение и лучше выйти сразу, в противном случае код получается запутанным.
TA>В качесте компромисса, было решено разрешать функциям выход только в двух моментах: сразу в начале, а если нет, то в конце.
TA>Надо подумать как можно реализовать это предложение.

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