Какой самый чистый способ написать это, если .. тогда логика? - PullRequest
8 голосов
/ 30 января 2009

Они оба делают одно и то же. Один способ лучше? Очевидно, что если я напишу код, я буду знать, что я сделал, но как насчет того, кто его читает?

if (!String.IsNullOrEmpty(returnUrl))
{
    return Redirect(returnUrl);
}
return RedirectToAction("Open", "ServiceCall");

ИЛИ

if (!String.IsNullOrEmpty(returnUrl))
{
   return Redirect(returnUrl);
}
else
{
    return RedirectToAction("Open", "ServiceCall");
}

Ответы [ 17 ]

30 голосов
/ 30 января 2009
return String.IsNullOrEmpty(returnUrl) ? 
            RedirectToAction("Open", "ServiceCall") : 
            Redirect(returnUrl);

Я предпочитаю это.

Или альтернатива:

return String.IsNullOrEmpty(returnUrl)  
            ? RedirectToAction("Open", "ServiceCall")  
            : Redirect(returnUrl);
24 голосов
/ 30 января 2009

Я считаю, что лучше убрать not (отрицание) и сначала получить положительное утверждение:

if (String.IsNullOrEmpty(returnUrl))
{
   return RedirectToAction("Open", "ServiceCall");
}
else
{
    return Redirect(returnUrl);
}

-или-

// Andrew Rollings solution
return String.IsNullOrEmpty(returnUrl) ? 
                    RedirectToAction("Open", "ServiceCall") : 
                    Redirect(returnUrl);
21 голосов
/ 30 января 2009

Одна проблема стиля:

if (String.IsNullOrEmpty(returnUrl))
{
    return RedirectToAction("Open", "ServiceCall");
}
return Redirect(returnUrl);

Когда вы отменяете двойное отрицание, оно читается намного лучше, независимо от того, какой стиль скобок вы выберете. Код, который читается лучше, всегда лучше;)

9 голосов
/ 30 января 2009

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

Я предпочитаю первое, но другие предпочитают только одну точку выхода из функции и, вероятно, предложат что-то вроде:

if (!String.IsNullOrEmpty(returnUrl))
{
   result = Redirect(returnUrl);
}
else
{
    result = RedirectToAction("Open", "ServiceCall");
}

return result;
9 голосов
/ 30 января 2009

второй способ лучше, нет путаницы в том, что вы имеете в виду ...

5 голосов
/ 30 января 2009

Мне нравится первый пример, потому что более очевидно, что этот отрывок вернет . Если оба return s находятся в заштрихованных блоках, требуется лишь немного больше умственных усилий, чтобы понять.

1 голос
/ 30 января 2009

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

if (!String.IsNullOrEmpty(returnUrl))
{
  // hooray, we have a URL
  return Redirect(returnUrl);
}
else
{
  // no url, go to the default place
  return RedirectToAction("Open", "ServiceCall");
}
1 голос
/ 30 января 2009

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

1 голос
/ 30 января 2009

Если это весь метод, то я бы сказал, что второй (с использованием else) немного более элегантен. Если у вас есть предыдущий код или (особенно) намного больше кода перед возвратом в другом случае, я бы сказал, что лучше не помещать else. Сохраняет от кода становится слишком отступ.

т.е. либо:

void myfunc()
{
    if (!String.IsNullOrEmpty(returnUrl))
    {
        return Redirect(returnUrl);
    }
    else
    {
        return RedirectToAction("Open", "ServiceCall");
    }
}

или

void myfunc()
{
    // ... maybe some code here ...

    if(!String.IsNullOrEmpty(returnUrl))
    {
       return Redirect(returnUrl);
    }

    // ... a bunch of other code ...

    return RedirectToAction("Open", "ServiceCall");
}
0 голосов
/ 30 января 2009

LFSR «другое» решение является наиболее удобным и читаемым.

Использование отдельного предложения else позволяет добавлять логику без непреднамеренного изменения потока. И достаточно плохо иметь несколько точек выхода, не скрывая две из них в одном выражении троичного оператора!

...