Есть ли преимущества быстрого выхода из метода или конструктора?

Question

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

Рассмотрим следующие два кодовых блока, оба из которых являются возможными конструкторамидля класса

public MyClass(OtherClass other){
    if (other != null) {
       //do something with other, possibly default values in this object
    }
}

и этого

public MyClass(OtherClass other){
    if (other == null)  return;

    //do something with other, possibly default values in this object
}

Есть ли какая-либо польза от выполнения последнего по сравнению с первым?Нет другого кода, который следует в конструкторе, просто код, который использует объект other для его создания.

Answer 1

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

Answer 2

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

Answer 3

Последний обычно легче читать, и если у вас есть несколько случаев, в которых вы бы прекратили, тогда это становится еще проще.Однако разницы в скорости нет.

Предположим, у вас есть функция, которая принимает Int32? и завершает работу, если значение равно null, even или больше 100.

Вы могли бы сделать

void fn( Int32? num ) {
    if ( num != null ) {
        if ( num < 100 ) {
            if ( num % 2 != 1 ) { 
                //method code

или что-то вроде

void fn( Int32? num ) {
    if ( num == null )
        return;

    if ( num > 100 )
        return;

    if (!(num % 2 != 1)) 
        return;

    //method code

Теперь этот пример немного глуп, я вас сейчас слышу, почему бы не собрать их всех в одну строкус || или && и в этом случае да.Но представьте, если проверка данных была намного сложнее, чем это?В итоге вы получите слишком много отступов, код будет намного сложнее читать.

Answer 4

Я пытался с этим конструктором

public AnotherExpense(string param)
    {
        if (param != null)
        {
            Console.WriteLine("test");
        }
    }

IL-код

.method public hidebysig specialname rtspecialname 
    instance void  .ctor(string param) cil managed
{
  // Code size       20 (0x14)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  call       instance void AccountParserCSV.Expense::.ctor()
  IL_0006:  ldarg.1
  IL_0007:  brfalse.s  IL_0013
  IL_0009:  ldstr      "test"
  IL_000e:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0013:  ret
} // 

, если вы измените его на

public AnotherExpense(string param)
    {
        if (param == null)
            return;

            Console.WriteLine("test");
    }

, вы получите

.method public hidebysig specialname rtspecialname 
    instance void  .ctor(string param) cil managed
{
  // Code size       21 (0x15)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  call       instance void AccountParserCSV.Expense::.ctor()
  IL_0006:  ldarg.1
  IL_0007:  brtrue.s   IL_000a
  IL_0009:  ret
  IL_000a:  ldstr      "test"
  IL_000f:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0014:  ret
}

видите «разницу» в строке 7?;-) edit - скомпилировано в 'Release' с VS2010

Answer 5

Специально для этого случая, в то время как вам (при условии, что вы человек) необходимо прочитать остальную часть исходного кода, чтобы добраться до конца метода, процессор этого не делает.Оператор block if в вашем первом примере оценивает условие, и если оно оценивается как false, выполнение просто переходит к концу метода.

Answer 6

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

Answer 7

Все дело в удобочитаемости и согласованности вашей базы кода. Длинный метод с разбросанными возвращаемыми значениями будет трудно прочитать (но в любом случае длинный метод плох). Пара пунктов охраны в начале метода может улучшить ясность и убрать ненужное вложение. Однако в конкретном примере, который вы привели, вам нужно будет спросить «почему здесь все в порядке?» Должны ли вы вызывать исключение или вместо него передавать нулевые объекты ?