Про то, что иметь много точек выхода из функции не есть хорошая практика, Вам кажется уже говорили... Но вот это
Таким кодом оптимизатор запутать на раз можно. Его не удобно модифицировать. Если вдруг потребуется оптимизатору указать hint, то при таком способе записи это будет сделать невозможно.
Я бы написал например так:
PS. Статью не читал - просто это первое, что бросилось в глаза.
PSS. А еще у Вас шрифт в статье дурацкий - читать сложно. :)

И то что дальше объявляется very good code - тоже под большим вопросом.

Anatoly MoskovskyВ статье четко написано в каких именно случаях правильнее отойти от правила единой точки выхода.
Да, есть, при беглом просмотре не заметил. Но все равно специально писать условия через not - менее наглядно. Потому как обычно условия формулируются по принципу "если то-то, то так-то", а не "если не то-то то так-то". Соответственно код не перегруженный кучей условий not более понятен для восприятия.

Ursego Я всё это не от нефиг делать написАл, а потому что наболело - работал я тогда в фирме
Это понятно, что плохое правило лучше чем никакое. Но не нужно же давать откровенно вредные советы. Про good code - я уже упомянул. Посмотрим на very good code. Я уж не говорю про то, что разобраться в 4 строках кода легче чем в 9 + объявление переменных и то что в последствии между этими строками кода еще чего-нибудь может получиться. Я не говорю, что таким способом записи фактически жестко прописывается план исполнения... Понимаете, 3 select'а написанные подряд - это совсем не тоже самое, что 1 select. В результате далеко не всегда будет одно и тоже.
UrsegoКакая логически разница сделать return сразу или через посредника, сначала перейдя к нему, чему хошь-не хошь будет посвящено несколько лишних строк?
Разница вот какая. Если у меня есть один return, то я точно знаю место в скрипте, которое будет исполняться непосредственно перед выходом из процедуры. Соответственно если мне понадобилось изменить процедуру так, чтобы для каких-то целей выделялся какой-то ресурс, то код по его освобождению я напишу 1 раз в конце функции. Если у меня много точек выхода, то я должен найти все и заменить
Так что польза от 1 точки выхода есть.
Кстати по поводу оформления таких кусочков кода
Я предпочитаю всегда писать
а не
Почему? 1. операторные скобки (да и обычные) полезно набирать "на автомате", а потом уже внутри писать текст - тогда потом не нужно будет нудно считать где забыл открыть/закрыть. 2. - когда понадобится внести второй оператор не нужно будет искать конец оператора который после if (а select может быть и на страницу и на две). 3. Можно просто напросто забыть дописать скобки - естественно получится не то, что нужно.

ЗоринАндрейКошмар! "найти и заменить"... нет слов.
1. Сколько точек выхода будет в данной функции? Посчитать по пальцам?
2. Оператор try есть не во всех версиях PB (по-моему с 7).

Anatoly Moskovskyкасается только предусловий, т.е. определения возможности выполнения основного кода ф-и. И в этот момент о выделении или освобождении ресурсов речь еще не идет.
Никто не сказал, что "parameters checking" не потянет необходимости выделения ресурсов. Например - передаются 2 параметра - имена файлов, а в функции необходимо чтобы файлы уже существовали. Поэтому мне нужно будет попытаться открыть - 1 файл и завершиться с ошибкой если его нет, а затем открыть второй файл и освободить первый файл и завершиться с ошибкой если нет второго. И это всего лишь "parameters checking".

ЗоринАндрейОдна.
Ну и к чему тогда твой пассаж?
Я понимаю, если бы это было ответом на это
Anatoly MoskovskyТак как иначе возникают чрезмерные вложенности if в которых часто забывают else и которые трудно модифицировать и отлаживать,
или вот это
UrsegoНо скажи, что используешь goto - забросают камнями. А какая нафиг разница? Не использовать этот удобный в определённых условиях оператор
Но оспаривать кодом с одной точкой возврата мой тезис
Локшин Маркиметь много точек выхода из функции не есть хорошая практика
и далее поясняющий пример по-моему как-то не логично.
ЗоринАндрейЕсли кто-то еще пользуется шестеркой - мне остается только посочувствовать.
Это было так, к слову :). Но ведь кто-то еще пользуется.

Anatoly MoskovskyА проверку наличия выделить в отдельный блок кода в начале ф-и, не мешая его с обработкой файла.

Я уже не говорю о том, что должна быть отдельная ф-я проверяющая наличие файла (допустим что в PB такой нет) , и тогда никаких проблем в освобождением ресурсов не будет. И читаемость кода повышается - явный вызов of_CheckIfFileExists понятен сразу, тогда как FileOpen; If ... еще нужно интерпретировать из контекста.
Ага щаз. А если голову включить? Проверка должна, именно должна захватывать файл чтобы никто с ним ничего не мог сделать. FileExists то проверить наличие сможет, но только для Вашего личного успокоения, и ничего более. Потому как сразу после исполнения FileExists он может быть кем угодно удален (сюрприз-сюрприз). И хоть обпишитесь вы своих функций проверки - все будет бестолку. Я же говорю - не нужно давать откровенно вредных советов.
Вы Анатолий (если сами не заметили) только что просто очень наглядно продемонстрировали к чему такой подход ведет.

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

Anatoly MoskovskyВсе описанные Вами проблемы могут возникнуть независимо от стиля кодирования, поэтому не вижу смысла обсуждать их в этом топике.
Проблемы -то возникнуть могут только как Вы их предлагаете решать? В таком духе:
Понимаете, если есть задача использовать ресурс, то проверять его наличие не захватив его - бесполезно. Есть, конечно, небольшие оговорки, но в общем и целом - картина такая. Зачем два раза проверять? Чтобы сохранить чистоту идеи? Почему тогда 3 раза не проверить?