Ненужный 'еще' оператор [дубликат]
Мне нужен был неизменный метод перемещения (тот, который не менял исходный массив), поэтому я применил принятый ответ @ Reid, чтобы просто использовать Object.assign для создания копии массива перед выполнением сращивания.
Array.prototype.immutableMove = function (old_index, new_index) {
var copy = Object.assign([], this);
if (new_index >= copy.length) {
var k = new_index - copy.length;
while ((k--) + 1) {
copy.push(undefined);
}
}
copy.splice(new_index, 0, copy.splice(old_index, 1)[0]);
return copy;
};
10 ответов
Обычно я бы предпочел, чтобы структура кода соответствовала структуре базовой «бизнес-логики». В этом случае мой подход будет зависеть от того, что представляет собой условие . Если это, например, проверка ошибок, которая обычно не выполняется, но может иногда использоваться, тогда асимметрия второй формы соответствует асимметрии логики.
doLotOfStuff();
if (condition) {
return foo;
}
return bar;
Но если любая возможность разумна и это просто выбор между ними, я бы позволил структуре кода показать эту симметрию.
doLotOfStuff();
if (condition) {
return foo;
} else {
return bar;
}
Код предназначен для чтения программисту, а не компилятору.
Я знаю, что без IDE, проверяющего это для меня, я почти всегда использую ненужные операторы else. Часто я нахожу, что сначала он читается лучше, но обычно удаляю его, когда на него указывают, поскольку я вижу тот факт, что это излишне, и тогда это вызывает у меня проблемы ...
Назовите меня плохим мальчиком, но я обычно использую:
doLotOfStuff();
return condition ? foo : bar;
Одно выражение возврата, очень удобочитаемое.
На мой взгляд, проверка затмения не очень полезна. Что вам следует делать, зависит от контекста вашей программы. Предложения Else предназначены для альтернатив (либо того, либо другого), тогда как переход к возврату (без предложения else) более уместен, когда у вас есть ряд условий, которые могут быть истинными, а падение - это скорее реакция по умолчанию, которую вы не делаете действительно вызывать слишком часто. Таким образом, вы используете и то, и другое в коде, который передает смысл, и поэтому проверка наличия или отсутствия бесполезна.
Хорошо , Я думаю, что использование множественного возврата не читается.
Я предпочитаю код, такой как:
String result = null;
doLotOfStuff();
if (condition) {
result = foo;
} else {
result = bar;
}
return result;
Множественные возвраты сложно понять. Но в вашем случае я предпочитаю postCheck
doLotOfStuff();
if (condition) {
return foo;
} else {
return bar;
}
Когда-то считалось (и, вероятно, до сих пор некоторые), что функции должны иметь одну точку входа (легко, но было актуально, если рассматривать язык ассемблера) и одну точка выхода.
Одна точка выхода хороша с точки зрения отладки (например, вы можете поместить одну контрольную точку / прерывание в одну строку и знать, что пройдете через нее), но может привести к ужасному вложению, поэтому чаще всего удобочитаемость имеет тенденцию выигрывать. из. Что дает наименьшее количество вложений, наименьшее количество строк кода и наиболее читаемый конечный результат? В конечном счете, это имеет тенденцию быть гораздо важнее всего остального.
Для того, что стоит последнее, лучше выразить следующим образом:
return condition ? foo : bar;
при условии, что условие не очень длинное.
Не беспокойтесь о предполагаемой «чистоте» кода. Это неуместное отвлечение. Сделайте вещи удобочитаемыми и в целом последовательными.
Я считаю, что эта форма
doLotOfStuff();
if (condition) {
return foo;
}
return bar;
более читабельна, чем форма с else, она меньше кода и более интуитивно понятна, если рассматривать ее как охранную инструкцию, как в рефакторинге Фаулера.
Если я прослежу следующий код, я замечу, что первый блок if является исключительным блоком кода. Однако, если я добавлю к нему "else" , Я могу считать, что оба являются рабочими блоками кода.
Кроме того, для основного рабочего блока могут быть несколько вложенных блоков. Я предпочитаю минимизировать вложенный уровень.
public String myMethod(input) {
if (!validate(input)) {
return "invalid input";
}
operation1();
if (someCondition) {
operation2();
} else {
operation3();
}
operation4();
operation5();
return operation6();
}
Некоторые программисты утверждают, что return в середине функции - плохая практика. Возможно, для простой проверки при входе в функцию, как в вашем первом примере, это нормально и приемлемо, но в других случаях я бы предпочел установить переменную result, как в ответе Jerome.
Некоторые известные эксперты по Java утверждают, что всегда нужно стремиться минимизировать объем вещей, и это тоже мое мнение.
Мои преподаватели в университете всегда мучили меня из-за того, что я должен писать такие вещи, как это было написано кем-то раньше:
String result = null;
doLotOfStuff();
if (condition) {
result = foo;
} else {
result = bar;
}
return result;
Переменный результат теперь имеет довольно большую область видимости. Вдобавок из-за большого количества вложений это может стать очень нечитаемым, если вы сделаете здесь немного больше, скажем, у вас есть еще один цикл for.
Думаю, это намного лучше:
doLotOfStuff();
return condition ? foo : bar;
Это прямо к делу. Я сразу вижу, что происходит, никаких фигурных скобок.
Думаю, очень хорошо
- Свести к минимуму область видимости
- Свести к минимуму отступ (то есть избегать фигурных скобок)
- Свести к минимуму длину метода
В этом помогает предупреждение «Ненужный оператор else».