Чи потрібні дужки в однорядкових операторах у JavaScript?

Я колись чув, що залишати фігурні дужки в однорядкових висловлюваннях може бути шкідливим для 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's 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;

Я думаю, що залишати дужки кращим, оскільки це робить код більш читабельним із менш зайвим синтаксисом.

Мій стиль кодування - ніколи не використовувати дужки, якщо код не є блоком. І ніколи не використовувати кілька операторів в одному рядку (розділених крапками з комою). Я вважаю, що це легко читати і чітко, і у мене ніколи не виникає проблем із визначенням обсягу заяв "якщо". Як результат, використання дужок на одиничному, якщо оператор стану вимагає 3 рядки. Подобається це:

 if (condition) {
   statement;
 }

Використання одного рядка, якщо оператор є кращим, оскільки він використовує менше вертикального простору і код є більш компактним.

Я б не змушував інших використовувати цей метод, але він працює для мене, і я не міг більше не погодитися з наведеними прикладами того, як вивільнення дужок призводить до помилок кодування / визначення обсягу.

Технічно ні, але в іншому випадку абсолютно Так !!!

Забудьте про "Це особисті переваги", "код буде працювати чудово", "він добре працює для мене", "він є більш читабельним" yada yada BS. Це може легко призвести до дуже серйозних проблем , якщо ви зробите помилку , і повірте мені , це дуже легко зробити помилку , коли ви кодуванням (не вірить?, Перевірити знаменитий Apple , йти на провал помилки ).

Аргумент: "Це особисті переваги"

Ні, це не так. Якщо ви не одноосібна команда, яка виїжджає на Марс, ні. Більшість часу там будуть інші люди, які читають / змінюють ваш код. У будь-якій серйозній команді з кодування це буде рекомендований спосіб, тому це не є «особистими уподобаннями».

Аргумент: "код буде працювати нормально"

Так само і з кодом спагетті! Це означає, що це нормально створити?

Аргумент: "для мене це добре працює"

У своїй кар’єрі я бачив так багато помилок, які були створені через цю проблему. Ви, напевно, не пам’ятаєте, скільки разів ви коментували '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;
}

але, можливо, тут помилку трохи простіше виявити (?)

Це справа стилю, але фігурні брекети добре запобігають можливим звисанням інших .

Є багато хороших відповідей, тому я не повторюсь, крім випадків, коли я можу сказати своє "правило", коли дужки можуть бути пропущені: за умов, які "повертаються" або "кидаються" (напр.) Як єдине твердження . У цьому випадку контролем потоку вже зрозуміло, що він закінчується:

Навіть «поганий випадок» може бути швидко ідентифікований (і зафіксований) через припинення контролю потоку. Це "правило" концепції / структури також застосовується до кількох мов.

if (x)
    return y;
    always();

Звичайно, це також, чому можна використовувати підводку ..

Ось чому це рекомендується

Скажімо, я пишу

if(someVal)
    alert("True");

Потім приходить наступний розробник і каже "Ой, мені потрібно щось інше зробити", тому вони пишуть

if(someVal)
    alert("True");
    alert("AlsoTrue");

Тепер, як ви бачите, "ТакожTrue" завжди буде правдою, тому що перший розробник не використовував дужки.

Зараз я працюю над мініфікатором. Навіть зараз я перевіряю це на двох величезних сценаріях. Експериментально я з’ясував: Ви можете видалити фігурні дужки ззаду, якщо, інакше, поки функціонувати *, якщо фігурні дужки не включають ';', 'return', 'for', 'if', 'else', 'while', 'do', 'function'. Незалежно від розривів рядків.

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.

Завжди знаходив це

if(valid) return;

на моє око легше, ніж

if(valid) {
  return;
}

також умовні, такі як

(valid) ? ifTrue() : ifFalse();

легше читати (моя особиста думка), ніж

if(valid) {
  ifTrue();
} else {
  ifFalse();
}

але я думаю, це зводиться до стилю кодування

Не відповідаючи на запитання безпосередньо, але нижче - короткий синтаксис про те, якщо умова в одному рядку

Наприклад:

var i=true;
if(i){
  dosomething();
}

Можна записати так:

var i=true;
i && dosomething();

У JavaScript існує багато проблем. Погляньте на те, що архітектор JavaScript Дуглас Крокфорд говорить про це . Якщо твердження if здається нормальним, але заява про повернення може створити проблему.

return
{
    ok:false;
}
//silent error (return undefined)

return{
    ok:true;
}
//works well in javascript

Я знайшов цю відповідь в пошуках подібного досвіду, тому вирішив відповісти на неї своїм досвідом.

Висловлювання без брекетів діють у більшості браузерів, проте я перевірив, що методи, що без брекетів, насправді не працюють у деяких браузерах.

Станом на 26 лютого 2018 року ця заява працює в Pale Moon, але не в Google Chrome.

function foo()
   return bar;

Початковий рівень відступу заяви повинен бути рівний кількості відкритих дужок над ним. (за винятком цитованих чи коментованих фігурних дужок або директив препроцесорів)

Інакше K&R буде хорошим стилем відступу. Щоб виправити їх стиль, рекомендую розміщувати короткі прості, якщо висловлювання в одному рядку.

if (foo) bar();    // I like this. It's 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
}

Іноді вони, здається, потрібні! Я сам не міг у це повірити, але вчора мені сталося на сесії Firebug (останній Firefox 22.0)

if (! my.condition.key)
    do something;

виконано зробити щось, незважаючи на те, що my.condition.key було правдою . Додавання дужок:

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...
}