Однажды я услышал, что оставлять фигурные скобки в однострочных операторах может быть вредно для JavaScript. Я больше не помню причины, и поиск в Google не сильно помог.
Есть ли что-нибудь, что делает хорошей идеей заключать все выражения в фигурные скобки в JavaScript?
Я спрашиваю, потому что все, кажется, делают это.
Но они рекомендуются. Если вы когда-либо расширите выражение, вам понадобятся.
Это совершенно верно
if (cond)
alert("Condition met!")
else
alert("Condition not met!")
Однако настоятельно рекомендуется, чтобы вы всегда использовали фигурные скобки, потому что если вы (или кто-то еще) когда-либо расширяете инструкцию, это будет необходимо.
Эта же практика следует во всех языках стиля синтаксиса C с привязкой. C, С++, Java, даже PHP все поддерживают один оператор строки без брекетов. Вы должны понимать, что вы сохраняете только два символа, а с некоторыми стилями крепления людей вы даже не сохраняете строку. Я предпочитаю полный стиль фигурной скобки (например, следующий), поэтому он имеет тенденцию быть немного дольше. Компромисс встречается очень хорошо с тем, что у вас очень четкая читаемость кода.
if (cond)
{
alert("Condition met!")
}
else
{
alert("Condition not met!")
}
Есть аспект читабельности - в том, что когда у вас есть составные операторы, это может очень запутать. Отступ помогает, но ничего не значит для компилятора/интерпретатора.
var a;
var b;
var c;
//Indenting is clear
if (a===true)
alert(a); //Only on IF
alert(b); //Always
//Indenting is bad
if (a===true)
alert(a); //Only on IF
alert(b); //Always but expected?
//Nested indenting is clear
if (a===true)
if (b===true)
alert(a); //Only on if-if
alert (b); //Always
//Nested indenting is misleading
if (a===true)
if (b===true)
alert(a); //Only on if-if
alert (b); //Always but expected as part of first if?
//Compound line is misleading
//b will always alert, but suggests it part of if
if (a===true) alert(a);alert(b);
else alert(c); //Error, else isn't attached
А затем есть аспект расширяемости:
//Problematic
if (a===true)
alert(a);
alert(b); //We're assuming this will happen with the if but it'll happen always
else //This else is not connected to an if anymore - error
alert(c);
//Obvious
if (a===true) {
alert(a); //on if
alert(b); //on if
} else {
alert(c); //on !if
}
Мысль такова: если у вас всегда есть квадратные скобки, вы знаете, как вставить в этот блок другие операторы.
В вопросе задается вопрос о операторах в одной строке. Тем не менее, во многих примерах приводятся причины не оставлять фигурные скобки на основе нескольких строк. Вполне безопасно не использовать скобки на одной линии, если это стиль кодирования, который вы предпочитаете.
Например, вопрос спрашивает, нормально ли это:
if (condition) statement;
Он не спрашивает, нормально ли это:
if (condition)
statement;
Я думаю, что оставлять скобки предпочтительнее, потому что это делает код более читаемым с менее излишним синтаксисом.
Мой стиль кодирования заключается в том, чтобы никогда не использовать скобки, если код не является блоком. И никогда не использовать несколько операторов в одной строке (разделенных точкой с запятой). Я считаю, что это легко читать и очищать и никогда не иметь проблем, связанных с высказываниями "если". В результате, используя скобки в одном условии if, требуется 3 строки. Вот так:
if (condition) {
statement;
}
Использование одной строки, если оператор предпочтительнее, потому что он использует меньшее вертикальное пространство, а код более компактен.
Я бы не принуждал других использовать этот метод, но он работает для меня, и я не мог больше не соглашаться с примерами, приведенными в том, как исключить скобки из-за ошибок кодирования/определения области видимости.
Технически нет, но в остальном абсолютно Да !!!
Забудьте о "личных предпочтениях", "код будет работать нормально", "он работал нормально для меня", "он более читабелен" yada yada BS. Это может легко привести к очень серьезным проблемам, если вы допустите ошибку и поверите мне, что очень легко ошибиться, когда вы кодируете (Не верьте?, посмотрите знаменитую ошибку Apple go to fail).
Аргумент: "Это личное предпочтение"
Нет это не так. Если только вы не команда из одного человека, уезжающая на Марс, нет. Большую часть времени будут другие люди, читающие/изменяющие ваш код. В любой серьезной команде программистов это будет рекомендуемый способ, поэтому он не является "личным предпочтением".
Аргумент: "код будет работать нормально"
Так же как и код спагетти! Означает ли это, что это нормально для создания?
Аргумент: "у меня все работало нормально"
В моей карьере я видел так много ошибок, созданных из-за этой проблемы. Вы, вероятно, не помните, сколько раз вы комментировали 'DoSomething()' и были озадачены тем, почему 'SomethingElse()' называется:
if (condition)
DoSomething();
SomethingElse();
Или добавил "SomethingMore" и не заметил, что он не будет вызван (даже если отступ подразумевает иное):
if (condition)
DoSomething();
SomethingMore();
Вот пример из жизни. Кто-то хотел выключить все журналы, чтобы запустить поиск и замену "console.log" => //"console.log":
if (condition)
console.log("something");
SomethingElse();
Видишь проблему?
Даже если вы думаете, "это так тривиально, я бы никогда этого не сделал"; помните, что всегда будет член команды с более низкими навыками программирования, чем вы (надеюсь, вы не худший в команде!)
Аргумент: "это более читабельно"
Если я что-то узнал о программировании, так это то, что простые вещи очень быстро становятся очень сложными. Очень часто это:
if (condition)
DoSomething();
превращается в следующее после того, как оно было протестировано с другими браузерами/средами/вариантами использования или добавлены новые функции:
if (a != null)
if (condition)
DoSomething();
else
DoSomethingElse();
DoSomethingMore();
else
if (b == null)
alert("error b");
else
alert("error a");
И сравните это с этим:
if (a != null) {
if (condition) {
DoSomething();
}
else {
DoSomethingElse();
DoSomethingMore();
}
} else if (b == null) {
alert("error b");
} else {
alert("error a");
}
PS: Бонусные баллы идут тем, кто заметил ошибку в приведенном выше примере.
Проблема ремонтопригодности отсутствует!
Проблема со всеми вами в том, что вы помещаете точки с запятой всюду. Вам не нужны фигурные скобки для нескольких операторов. Если вы хотите добавить инструкцию, просто используйте запятые.
if (a > 1)
alert("foo"),
alert("bar"),
alert("lorem"),
alert("ipsum");
else
alert("blah");
Это действительный код, который будет работать так, как вы ожидаете!
В дополнение к причине, упомянутой @Josh K (что также относится к Java, C и т.д.), одна специальная проблема в JavaScript - автоматическая точка с запятой. Из примера в Википедии:
return
a + b;
// Returns undefined. Treated as:
// return;
// a + b;
Таким образом, это может также дать неожиданные результаты, если они используются следующим образом:
if (x)
return
a + b;
Не намного лучше писать
if (x) {
return
a + b;
}
но, возможно, здесь ошибка немного легче обнаружить (?)
Это вопрос стиля, но фигурные скобки хороши для предотвращения возможного dangling else.
Нет никаких причин программирования для использования фигурных скобок в операторах одной строки.
Это относится только к предпочтениям и читабельности кодеров.
Из-за этого ваш код не сломается.
Вот почему рекомендуется
Скажем, пишу
if(someVal)
alert("True");
Затем появляется следующий разработчик и говорит: "О, мне нужно сделать что-то еще", поэтому они пишут
if(someVal)
alert("True");
alert("AlsoTrue");
Теперь, как вы видите, "AlsoTrue" всегда будет правдой, потому что первый разработчик не использовал фигурные скобки.
В настоящее время я работаю над minifier. Даже сейчас я проверяю его на два огромных сценария. Экспериментально я узнал: Вы можете удалить фигурные скобки за, если, еще, while, function *, если фигурные фигурные скобки не включают ';', 'return', 'for', 'if', 'else', 'while', ' делать",„функция“. Независимые разрывы строк.
function a(b){if(c){d}else{e}} //ok
function a(b){if(c)d;else e} //ok
Конечно, вам нужно заменить закрывающую фигуру точкой с запятой, если она не будет следовать за другой закрывающей скобкой.
Функция не должна заканчиваться запятой.
var a,b=function()c; //ok *but not in Chrome
var b=function()c,a; //error
Проверено на Chrome и FF.
В javascript есть много проблем. Взгляните на JavaScript-архитектор Дуглас Крокфорд говорит об этом Оператор if кажется прекрасным, но return может возникнуть проблема.
return
{
ok:false;
}
//silent error (return undefined)
return{
ok:true;
}
//works well in javascript
Я нашел этот ответ в поисках подобного опыта, поэтому решил ответить на него своим опытом.
Операторы без привязки работают в большинстве браузеров, однако я тестировал, что безрецептурные методы на самом деле не работают в каком-то браузере.
По состоянию на 26 февраля 2018 года это выражение работает в Pale Moon, но не в Google Chrome.
function foo()
return bar;
Не отвечающий на вопрос напрямую, но ниже приведен короткий синтаксис о том, если условие на одной строке
Пример:
var i=true;
if(i){
dosomething();
}
Можно написать так:
var i=true;
i && dosomething();
Иногда они кажутся необходимыми! Я сам не мог поверить, но вчера мне пришло в голову Firebug (недавний Firefox 22.0), который
if (! my.condition.key)
do something;
выполнил что-то, несмотря на то, что my.condition.key был true. Добавление фигурных скобок:
if (! my.condition.var) {
do something;
}
исправлено это материя. Есть мириады примеров, где, по-видимому, работает без брекетов, но в этом случае это определенно не было.
Люди, которые, как правило, ставят несколько строк на строке, должны, безусловно, всегда использовать скобки, конечно, потому что такие вещи, как
if (condition)
do something; do something else;
трудно найти.
Я хотел бы отметить, что вы также можете оставить фигурные скобки от другого. Как видно из этой статьи Джона Ресига.
if(2 == 1){
if(1 == 2){
console.log("We will never get here")
}
} else
console.log("We will get here")
Существует способ достижения нескольких линейных не фигурных скобок, если утверждения.. (Вау, какой английский..), но это своего рода tedius:
if(true)
funcName();
else
return null;
function funcName(){
//Do Stuff Here...
}
Начальный уровень отступа оператора должен быть равен числу открытых фигурных скобок над ним. (исключая цитируемые или комментируемые фигурные скобки или символы в директивах препроцессора)
В противном случае K & R будет хорошим отступом. Чтобы исправить их стиль, я рекомендую размещать короткие простые операторы if на одной строке.
if (foo) bar(); // I like this. It also consistent with Python FWIW
вместо
if (foo)
bar(); // not so good
Если бы я писал редактор, я бы сделал его кнопку автоматического формата, сосать планку до той же строки, что и foo, и я бы вставлял фигурные скобки вокруг бара, если вы нажимаете return, прежде чем это будет выглядеть так:
if (foo) {
bar(); // better
}
Затем легко и последовательно добавлять новые выражения выше или ниже в пределах тела оператора if
if (foo) {
bar(); // consistent
baz(); // easy to read and maintain
}
Всегда находил, что
if(valid) return;
легче на моем глазу, чем
if(valid) {
return;
}
также условные, такие как
(valid) ? ifTrue() : ifFalse();
легче читать (мое личное мнение), а не
if(valid) {
ifTrue();
} else {
ifFalse();
}
но я предполагаю, что это сводится к стилю кодирования
Есть много хороших ответов, поэтому я не буду повторяться, за исключением того, чтобы сказать мое "правило", когда фигурные скобки могут быть опущены: при условиях, которые возвращают или бросают (например,) в качестве единственного утверждения. В этом случае управление потоком уже ясно, что его прекращение:
Даже "плохой случай" может быть быстро идентифицирован (и устранен) благодаря прекращению управления потоком. Это понятие/структура "правило" также применимо к ряду языков.
if (x)
return y;
always();
Конечно, именно поэтому можно использовать линтер.