Явное или неявное использование оператора управления выполнением

Question

я иногда пользуюсь

if (this._currentToolForeColor.HasValue)
    return this._currentToolForeColor.Value;
else
    throw new InvalidOperationException();

В другой раз я использую

if (this._currentToolForeColor.HasValue)
    return this._currentToolForeColor.Value;
throw new InvalidOperationException();

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

Это идет еще дальше, поскольку вы можете использовать другие операторы управления выполнением, такие как тормоза или продолжить:

while(something)
{
    if(condition)
    {
        DoThis();
        continue;
    }
    else
        break;
}

против

while(something)
{
    if(condition)
    {
        DoThis();
        continue;
    }
    break;
}

РЕДАКТИРОВАТЬ 1: Да, пример (ы) цикла отстой, потому что они синтетические (т.е. составлены для этого вопроса) в отличие от первого, который является практичным.

Answer 1

Ошибка рано.

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

public void SomeFunction(object someParameter)
{
    if (someParameter == null) throw new ArgumentNullException("someParameter", "Value cannot be null");

    // Use the parameter here for stuff
    SomeOtherFunction(someParameter, Whichway.Up);
}

То же самое касается оператора return. Если ваш метод завершен, не оборачивайте вещи большими if утверждениями, просто return и уходите оттуда.

См. уменьшение цикломатической сложности для других примеров этой концепции. Обратите внимание, что в моем примере есть только один путь к коду, это только вопрос того, как далеко вы можете продвинуться с заданными параметрами. Вложенные if s и фигурные скобки (даже если вы не используете фигурные скобки, как в вашем примере) - все они оказывают большее влияние на читабельность, чем разница между вашими примерами.

Answer 2

while(something) {
    if(condition)
    {
        DoThis();
        continue;
    }
    else
        break; }

То же самое, что и следующее:

while(something && condition)
{
     DoThis();
}

К вашему вопросу: всегда лучше быть более точным, как протекает управление, даже если оно выглядит избыточным (например, избыточные соединения в любом случае оптимизируются). Так что, если (cond) вернет x, то бросить y - это хорошо.

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

Answer 3

Первый и второй параметры эквивалентны компилятору. Но для человека, читающего код, первый вариант определенно более понятен для целей и легче читается.

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

Answer 4

Resharper порекомендует вам использовать это:

if( someCondition )
   return foo;

throw new InvalidArgumentException();

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

if( someConditiion )
{
   return foo;
}
else
{
   throw new ....
}

Относительно ваших примеров. ИМХО, оба твоих примера кода отстой. Почему бы не написать это так:

while( something )
{
    if( !condition ) 
        break;

    DoStuff();
}

Answer 5

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

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

У него есть свои применения, но будьте осторожны, вы не хотите, чтобы какой-то комментарий появлялся у другого разработчика в команде, говорящего

ЗДЕСЬ БУДУТ ДРАКОНЫ !!!

Answer 6

Для лучшего и более чистого кода, я думаю, что лучше всегда выбирать эту форму:

if(condition)
{
   //do stuff
}
else
{
   //do stuff
}

.. и т. Д.

Это просто вопрос «вкуса», но даже если у вас больше строк кода, это легко читается, потому что вам не нужно ни интерпретировать, ни понимать, вы можете легко следить за потоком кода пальцем. Поэтому для меня всегда остальное, даже если возврат предотвращает откат к следующему коду, всегда заключает в скобки событие, если у вас есть одна строка if / else и т. Д.

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

Answer 7

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