Если честно, никогда не понимал этого правила. Оно разумно в C, когда надо в конце функции освобождать ресурсы, и всякие return-ы в середине легко приводят к утечкам. В современных ЯП оно не нужно, имхо.

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

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

G>В принципах структурного программирования закреплено что подпрограмма должна иметь одну точку входа и одну точку выхода.
G>При наличии исключений это правило нарушается, поэтому париться строго об одной точке выхода не стоит.
G>Если подпрограмма не может сделать свою работу, то она должна выкидывать исключение как можно раньше.
Так вместо того, чтоб выкидывать исключение можно же сделать return "ERROR". Как же это решение(выкидывать исключение) решает задание — "...реализовать это предложение..."?
G>Чтобы не возникало проблем с читаемостью просто делайте короткие подпрограммы, которые умещаются на одном экране стандартным шрифтом.

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

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

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

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

G>>>>В принципах структурного программирования закреплено что подпрограмма должна иметь одну точку входа и одну точку выхода.
G>>>>При наличии исключений это правило нарушается, поэтому париться строго об одной точке выхода не стоит.
G>>>>Если подпрограмма не может сделать свою работу, то она должна выкидывать исключение как можно раньше.
TA>>>Так вместо того, чтоб выкидывать исключение можно же сделать return "ERROR".
G>>А что такое ERROR?
TA>Error это переменная например обозначающая ошубку.
Есть функция, которая что-то считает, там возникает деление на ноль, или взятие корня из отрицательного числа. Какое значение будет у переменной Error?

TA>Ты предлагаешь выкидывать исключение. Так вот, я говорю, что вместо того, чтоб выкидывать исключение можно же сделать return "ERROR"
Неправильно ты говоришь. Можешь сразу признать это, а можем продолжить дискуссию и ты поймешь что ты неправ.

Можно пример "чистоты"?

Чем

Result result = SomeFunction();
if (result == Result.Error)
{
    ... 
}

принципиально отличается от

try
{
    SomeFunction()
}
catch (Exception exception)
{
    ...
}

?

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

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

ТЗИ>Чем

ТЗИ>

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

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

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

ТЗИ>

ТЗИ>    SomeFunction()
ТЗИ>

ТЗИ>?

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

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

Здравствуйте, 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 разве того же уровня что и первый? Имхо, это несколько обманчивый способ форматирования. На самом деле здесь лесенка.

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

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

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

TA>Спасибо

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

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

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

Если речь о структурном программировании, то там говорится не только о функциях, а б структурах кода. Это могут быть и управляющие конструкции циклов, операторы ветвления. Запрещается использовать любые формы выхода из этих конструкций, т.е. "return", "break", "continue", "goto". Исключения тоже можно присоединить к способам покинуть структуру кода.

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

int Compare1(float a, float b)
{
    if (a == b)
        return 0;
    if (a < b)
        return -1;
    return 1;
}

int Compare2(float a, float b)
{
    int result = 0;
    if (a != b)
    {
        if (a < b)
           result = -1
        else
           result = 1;
    }
    return result;
}

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

Однако, работаю с человеком, который предпочитает придерживаться правила single point of entry and exit. И вариант Compare2 для него понятнее, если он не шутит.

Так что, прежде чем думать над компромиссом, советую хорошо подумать, следует ли придерживаться такого правила. Возможно устроить голосование (в команде и/или на форуме).

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

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

Можно предложить не синтаксис, а общий подход к организации тела функции:

type function(params  ...)
{
  try
  {
    // Проверка предусловий
    // ...
    if (!preconditions_ok)
      return some_error;

    type retval = some_initial_value;
    // Содержательная часть функции
    // ... ...
    retval = some_value;
    // ... ...

    // Возврат значения
    return retval;
  }
  catch(...)
  {
    // Непредвиденные ситуации
    handle_all_exceptions();
  }
}

TA>Спасибо

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

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

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

G>>>В принципах структурного программирования закреплено что подпрограмма должна иметь одну точку входа и одну точку выхода.
G>>>При наличии исключений это правило нарушается, поэтому париться строго об одной точке выхода не стоит.
G>>>Если подпрограмма не может сделать свою работу, то она должна выкидывать исключение как можно раньше.
TA>>Так вместо того, чтоб выкидывать исключение можно же сделать return "ERROR".
G>А что такое ERROR?
Error это переменная например обозначающая ошубку. Ты предлагаешь выкидывать исключение. Так вот, я говорю, что вместо того, чтоб выкидывать исключение можно же сделать return "ERROR"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо

Вопрос то озвучьте ?

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

M>Вопрос то озвучьте ?
Надо подумать как можно реализовать это предложение(Компрамисс который был достигнут). И какой синтаксис можно предложить

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

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

G>>В принципах структурного программирования закреплено что подпрограмма должна иметь одну точку входа и одну точку выхода.
G>>При наличии исключений это правило нарушается, поэтому париться строго об одной точке выхода не стоит.
G>>Если подпрограмма не может сделать свою работу, то она должна выкидывать исключение как можно раньше.
TA>Так вместо того, чтоб выкидывать исключение можно же сделать return "ERROR".
А что такое ERROR?

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

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

M>>Вопрос то озвучьте ?
TA>Надо подумать как можно реализовать это предложение(Компрамисс который был достигнут). И какой синтаксис можно предложить

Сильно зависит от языка програмирования и инструментов. Например LINT предполагаю можно научить ловить несколько точек выхода.

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

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

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

M>>>Вопрос то озвучьте ?
TA>>Надо подумать как можно реализовать это предложение(Компрамисс который был достигнут). И какой синтаксис можно предложить

M>Сильно зависит от языка програмирования и инструментов. Например LINT предполагаю можно научить ловить несколько точек выхода.
Ну наприме в С++ или С#. Только в моем случае это не несколько точек выхода, а только 2 — сразу вначале или в конце

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

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

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

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

А тем временем во многих языках предусмотрены сопрограммы, которые выходят из одной и той же функции по многу раз (и заходят обратно).

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

TA>Error это переменная например обозначающая ошубку. Ты предлагаешь выкидывать исключение. Так вот, я говорю, что вместо того, чтоб выкидывать исключение можно же сделать return "ERROR"

Это значит, что нужно обрабатывать ошибку на месте вызова или же передавать её наверх.

Т.е. выполнять нужно две задачи — обработку ошибки и диспетчеризацию на обработку.

В ряде случаев, так и делается, ибо это необходимость. Напрмиер если ты посмотришь, все win32 функции возвращают BOOL а COM возвращают HRESULT. А функции на каждый системый вызов проверяют результат и обрабатывают.

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

Исключения позволяют локализовать обработку ошибок в конкретном слое. Т.е. они полностью берут на себя диспетчеризацию ошибок, при этом глубина вложенности вызовов значения не имеет

Соответственно этим можно воспользоваться и исключить из кода не только диспетчеризацию, но и обработку ошибок.

Все это приводит к чистоте кода, а это в свою очередь приводит к повышению качества софта.

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

TA>Специалист Б утверждал — часто функция распознает когда не стоит продолжать выполнение и лучше выйти сразу, в противном случае код получается запутанным.
ИМХО это мнение является верным.

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

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

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

толсто

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

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

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

Здравствуйте, 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;