Какой лучший вариант?

Question

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

ИЛИ

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

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

Answer 1

Могу ли я просто заявить, что если вы используете вторую форму, вы не добавляете безвозмездный уровень отступов ectra. Так insrtead из:

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

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

говорят:

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

    /* no Exit needed, but now we got what I think unpleasing code: 
    having a indentation level and a begin-end statement */ 
end; 

Answer 2

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

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

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

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

Answer 3

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

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

v.s.

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

Answer 4

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

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

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

Особого раздражение я вижу подобные "else" в:

if (some condition) 
    return false; 
else 
    keep going; 

ли они думают, что поток управления каким-то образом собирается уйти из пункта "then"?

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

Я предпочитаю:

if not Eval then Exit; 

, так как код выглядит чище, что путь.