Событие не запускается через домен приложений

Для простого оператора if без слишком большого количества строк кода с множественными возвратами проблем нет. Однако ничто меня так не бесит, как:

function doTemperatureCalculations(double temperature) {
  if (temperature < 20) {
    /* 
      Gazillion lines of code here .....
     */
    return "Very cold!";
  } else if (temperature < 40) {
    /*
      Another gazillion loc .....
     */
    return "Summer in the North Pole.";
  } else {
    /*
      Multiple returns embedded throughout ....
     */
  }
}

Нет смысла. Вы добавляете ненужные семантические и другие накладные расходы для абсолютно нулевой пользы. Когда вы вернетесь, вы вернетесь, и контроль закончится. Делать вид, что что-то еще является излишним и просто создает впечатление, что вы не знаете, что делает оператор return.

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

Таким образом, аргумент является одиночным или составным оператором.

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

ПС. Я всегда посылал температуру в градусах по Цельсию, ой, только что сломал вашу функцию!

public String getTemperatureMessage(double temp)
{
    String retval = null;
    if(temp < 32)
        retval = "Freezing";
    else if(temp < 60)
        retval = "Brr";
    else if(temp < 80)
        retval = "Comfortable";
    else
        retval = "Too hot";
    return retval;
}

Для простых однострочных Я склонен опускать else, но если есть более сложные блоки if, я предпочитаю else, чтобы было ясно, что условия взаимоисключающие.

Единственной возможной альтернативой в этом частном случае является использование условного оператора ?:.

public String getTemperatureMessage(double temp) {
    return temp < 32 ? "Freezing"
         : temp < 60 ? "Brr"
         : temp < 80 ? "Comfortable"
         : "Too hot";
}

Остался вопрос, как это читается для начинающих.

Ссылки

• Условный оператор JLS 15.25 ?:
  • Оператор является правоассоциативным, поэтому такая вложенность оператора будет работать "как ожидается"

Связанные вопросы

• Тернарный или нет в тройной?

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

int do_something(int arg1)
{
  if (arg1 > MAX_ARG1_VALUE)
    return ARG1_ERROR;
  ... main guts of code here
  return 0;
}

, чем сказать:

int do_something(int arg1)
{
  if (arg1 > MAX_ARG1_VALUE)
    return ARG1_ERROR;
  else
  {
    ... main guts of code here
    return 0;
  }
}

или

int do_something(int arg1)
{
  if (arg1 <= MAX_ARG1_VALUE)
  {
    ... main guts of code here
    return 0;
  }
  else
    return ARG1_ERROR;

Это различие становится особенно важным, если есть несколько вещей, которые могут «пойти не так», например.

int do_something(int arg1)
{
  if (arg1 > MAX_ARG1_VALUE)
    return ARG1_ERROR;
  ... some code goes here
  if (something_went_wrong1)
    return SOMETHING1_ERROR;
  ... more code goes here
  if (something_went_wrong2)
    return SOMETHING2_ERROR;
  ... more code goes here
  if (something_went_wrong3)
    return SOMETHING3_ERROR;
  return 0;
}

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

все хорошо. без «иначе» эта строка

if(temp < 80)
    return "Comfortable";

была бы неубедительной. с "еще" ясно, что есть другие предварительные условия.

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

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

if (error condition) {  
  do some stuff;
  return;
} else {
  do stuff;
  if (other error condition) {
     do some stuff1;
     return;
  } else {
     do some other stuff;
     return

  }
}

Приведенный ниже код снижает уровень вложенности, что снижает сложность кода:

if (error condition) {
  do some stuff;
  return;
}
do stuff;
if (other error condition) {
  do some stuff1;
  return;
}
do some other stuff;
return;

В вашем примере это легко сделать в любом случае. Но во многих случаях вам лучше использовать таблицу поиска для такого рода вещей и читать значения из файла/базы данных. Для эффективности в C это часто кодируется как массив структур.

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

Я могу думать о преимуществе остальных. Если вы хотите добавить новый последний случай, без elses вы можете забыть добавить if к текущему «Too Hot Condition», если, скажем, вы хотите добавить «Dying» на 120 или что-то в этом роде. в то время как с elses вы знаете, что вам нужно, чтобы финал else был перед «Dying», поэтому вы, скорее всего, подумаете о том, чтобы поставить else перед «Too Hot». Кроме того, если вы просто поставите else на «Dying», вы получите ошибку компиляции, которая заставит вас задуматься.

Кто использует IF/ELSE IF..., когда можно использовать оператор SWITCH?

Я предпочитаю один оператор RETURN — несколько операторов return могут затруднить отладку...

Это зависит от многих факторов, например, от того, насколько сложен ваш код. В таком простом примере я бы поместил возвраты в ту же строку, что и ifs, и не использовал elses. Структура и поведение понятны:

public String getTemperatureMessage(double temp)
{
    if(temp < 32) return "Freezing";
    if(temp < 60) return "Brr";
    if(temp < 80) return "Comfortable";
    return "Too hot";
}

Когда у меня есть более сложный код, я считаю полезным не выходить из вложенности с помощью возвратов или продолжения/разрыва, а присваивать значения переменным состояния или результата. Затем я также включу {}, даже если блок представляет собой один оператор, в основном для сохранения согласованности в том, как структура представлена ​​в коде, а также для того, чтобы немного снизить риск того, что последующие изменения забудут преобразовать оператор в блок.

Если бы этот пример был более сложным, я бы, вероятно, закодировал его так:

public String getTemperatureMessage(double temp) {
    String result;
    if(temp < 32) {
        result = "Freezing";
    } else {
        if(temp < 60) {
            result = "Brr";
        } else {
            if(temp < 80) {
                result = "Comfortable";
            } else {
                result = "Too hot";
            }
        }
    }
    return result;
}