Каков более оптимальный вариант? [закрытый]

Бывают случаи, когда подходит любой метод. Однако обычно первый предлагает более читаемый код и лучший поток управления. Я не очень знаком с программированием на Delphi, но в C # я всегда стараюсь по возможности использовать первое. Судя по всему, я не вижу причин, по которым подход должен отличаться в Delphi.

Чтобы перечислить некоторые из преимуществ:

• Нет необходимости делать отступ в последующем коде.
• Легче расширить на несколько условий. (Просто добавьте дополнительные операторы if, а не логические операторы, что сделает ситуацию более ясной в ИМО.)
• Идея, что вы «отказываетесь» от метода, а не выбираете его, более эстетична, поскольку следующий код должен выполняться в «нормальный» случай.

Тем не менее, бывают ситуации, когда второй вариант более уместен. В частности,

Я думаю, это вопрос предпочтений. Однако, если у вас есть ряд проверок, которые вы должны выполнить перед тем, как выполнять «настоящую работу», тогда первая форма (IMO) выглядит аккуратнее, и ее легче отслеживать. Например:

procedure MyProc(Eval: Boolean);
begin
    if not Eval then
        Exit;
    if not Eval2 then
        Exit;
    /* do stuff */
    /* do more stuff */ 
end;

vs

procedure MyProc(Eval: Boolean);
begin
    if Eval then
    begin
        if Eval2 then
        begin
            /* do stuff */
            /* do more stuff */
        end;
    end;
end;

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

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

У меня были люди, которые реорганизовали код, который я написал следовать «правилам», и это почти всегда заканчивалось трясиной нечитаемого кода из-за чрезмерных отступов. Надо было либо оставить все, либо сделать как следует,

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

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

И, кажется, используется много, учитывая тот факт, что exit (returnvalue) был добавлен в D2009 (и FPC имеет его в течение десяти лет)

Я думаю, что чем меньше точек выхода имеет сегмент кода, тем лучше, поэтому его легче читать и понимать. Отмечать хуже, чем отлаживать чужую 100-строчную функцию и обнаруживать 12 различных ситуаций, которые могут привести к ее преждевременному возврату.

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

Так каково мое соглашение? Ах ... Я прагматичен, у меня нет правил. Если возможно выпрыгнуть из окна в первых нескольких строках, я так понимаю, потому что мне не нужно помнить, когда я редактирую код, что какой-то «неответный вызов функции» все еще может быть активен в любой момент во время выполнения функции.

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

Это более сложный вызов, если вы все настраиваете и должны разрушать их, поскольку выпрыгивание может заставить вас жонглировать 17 состояниями кота Шредингера в вашей голове при внесении изменений.

На мой взгляд, ни то, ни другое не является правильным ответом.

Правильным решением было бы включить в процедуру только части «делать что-нибудь» и «делать больше». Затем оберните вызов процедуры в оператор if, вызывая его только при необходимости.

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

I prefer:

if not Eval then Exit;

because the code looks cleaner that way.