As chaves são necessárias em declarações de uma linha em JavaScript?

Certa vez ouvi que deixar as chaves em declarações de uma linha poderia ser prejudicial em JavaScript. Não me lembro mais do raciocínio e uma pesquisa no Google não ajudou muito. Existe alguma coisa que faça uma boa ideia cercar todas as instruções dentro de chaves em JavaScript?

Eu estou perguntando, porque todo mundo parece fazer isso.

Não

Mas eles são recomendados. Se você expandir a afirmação, precisará deles.

Isso é perfeitamente válido

if (cond) alert("Condition met!") else alert("Condition not met!") 

No entanto, é altamente recomendável que você sempre use chaves, porque se você (ou outra pessoa) expandir a declaração, isso será necessário.

Essa mesma prática segue em todas as linguagens de estilo de syntax C com contraventamento. C, C ++, Java, até mesmo PHP, suportam uma instrução de linha sem chaves. Você tem que perceber que você está salvando apenas dois personagens e com alguns estilos de pessoas que você não está salvando uma linha. Eu prefiro um estilo de chave completo (como segue), então ele tende a ser um pouco mais longo. A desvantagem é muito bem satisfeita com o fato de você ter uma legibilidade de código extremamente clara.

 if (cond) { alert("Condition met!") } else { alert("Condition not met!") } 

Há um aspecto de legibilidade – quando você tem instruções compostas, pode ficar muito confuso. (Recuar ajuda, mas não significa nada para o compilador / intérprete)

 var a; var b; var c; //Indenting is clear if (a===true) alert(a); //On on IF alert(b); //Always //Indenting is bad if (a===true) alert(a); //On 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 

E depois há um aspecto de extensibilidade:

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

(O raciocínio é que, se você sempre tiver os colchetes, você sabe inserir outras instruções dentro desse bloco).

A pergunta é sobre declarações em uma linha. No entanto, os muitos exemplos fornecidos mostram razões para não deixar de lado chaves com base em várias instruções de linha. É completamente seguro não usar parênteses em uma linha, se esse for o estilo de codificação que você preferir.

Por exemplo, a pergunta pergunta se está tudo bem:

  if (condition) statement; 

Não pergunta se está tudo bem:

  if (condition) statement; 

Acho que deixar os colchetes fora é preferível porque torna o código mais legível com uma syntax menos supérflua.

Meu estilo de codificação é nunca usar colchetes a menos que o código seja um bloco. E nunca usar várias instruções em uma única linha (separadas por ponto e vírgula). Acho isso fácil de ler e limpar e nunca ter problemas de escopo em instruções ‘if’. Como resultado, o uso de colchetes em uma única instrução de condição if exigiria três linhas. Como isso:

  if (condition) { statement; } 

Usando uma linha, se a instrução for preferível, porque ela usa menos espaço vertical e o código é mais compacto.

Eu não forçaria os outros a usar esse método, mas funciona para mim e eu não poderia discordar mais com os exemplos fornecidos sobre como deixar de fora os colchetes leva a erros de codificação / escopo.

Não há problema de manutenção!

O problema com todos vocês é que você coloca ponto e vírgula em todos os lugares. Você não precisa de chaves para várias instruções. Se você quiser adicionar uma declaração, apenas use vírgulas.

 if (a > 1) alert("foo"), alert("bar"), alert("lorem"), alert("ipsum"); else alert("blah"); 

Este é um código válido que será executado como você espera!

Além do motivo mencionado por @Josh K (que também se aplica a Java, C etc.), um problema especial em JavaScript é a inserção automática de ponto-e-vírgula . Do exemplo da Wikipedia:

 return a + b; // Returns undefined. Treated as: // return; // a + b; 

Então, isso também pode gerar resultados inesperados, se usado assim:

 if (x) return a + b; 

Não é muito melhor escrever

 if (x) { return a + b; } 

mas talvez aqui o erro seja um pouco mais fácil de detectar (?)

É uma questão de estilo, mas chaves são boas para prevenir possíveis pendentes .

Absolutamente sim

Esqueça “É preferência pessoal”, “o código funcionará muito bem”, “tem funcionado bem para mim”, “é mais legível” yada yada BS.

Argumento: “É preferência pessoal”

Não não é. A menos que você seja um time de um homem saindo em Marte, não. Na maioria das vezes, haverá outras pessoas lendo / modificando seu código. Em qualquer equipe séria de codificação, essa será a maneira recomendada, por isso não é uma ‘preferência pessoal’.

Argumento: “o código funcionará bem”

O mesmo acontece com o código de espaguete! Isso significa que está tudo bem criá-lo?

Argumento: “tem funcionado bem para mim”

Na minha carreira eu vi tantos bugs criados por causa desse problema. Você provavelmente não se lembra de quantas vezes você comentou 'DoSomething()' e confundiu por que 'SomethingElse()' é chamado:

 if (condition) DoSomething(); SomethingElse(); 

Ou adicionou ‘SomethingMore’ e não percebeu que não será chamado (mesmo que o recuo indique o contrário):

 if (condition) DoSomething(); SomethingMore(); 

Aqui está um exemplo da vida real que eu tive. Alguém queria transformar todo o logging para que eles //"console.log" find & replace "console.log" => //"console.log" :

 if (condition) console.log("something"); SomethingElse(); 

Veja o problema?

Mesmo se você pensar, “estes são tão triviais, eu nunca faria isso”; Lembre-se de que sempre haverá um membro da equipe com habilidades de programação inferiores a você (espero que você não seja o pior da equipe!)

Argumento: “é mais legível”

Se aprendi alguma coisa sobre programação, é que as coisas simples se tornam muito complexas muito rapidamente. É muito comum que isso:

 if (condition) DoSomething(); 

se transforma no seguinte depois de ter sido testado com diferentes navegadores / ambientes / casos de uso ou novos resources são adicionados:

 if (a != null) if (condition) DoSomething(); else DoSomethingElse(); DoSomethingMore(); else if (b == null) alert("error b"); else alert("error a"); 

E compare com isso:

  if (a != null) { if (condition) { DoSomething(); } else { DoSomethingElse(); DoSomethingMore(); } } else if (b == null) { alert("error b"); } else { alert("error a"); } 

PS: pontos de bônus vão para quem percebeu o bug no exemplo acima

Não há razão de programação para usar as chaves em instruções de uma linha.

Isso só se resume a preferências e legibilidade dos codificadores.

Seu código não vai quebrar por causa disso.

Por isso é recomendado

Digamos que eu escreva

 if(someVal) alert("True"); 

Então o próximo desenvolvedor vem e diz “Oh, eu preciso fazer outra coisa”, então eles escrevem

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

Agora, como você pode ver, o “AlsoTrue” sempre será verdadeiro, porque o primeiro desenvolvedor não usou chaves.

Atualmente estou trabalhando em um minifator. Até agora eu confiro em dois scripts enormes. Experimentalmente eu descobri: Você pode remover as chaves para, if, else, while, function * se as chaves não incluírem ‘;’, ‘return’, ‘for’, ‘if’, ‘else’, ‘while’, ‘do’, ‘function’. Quebras de linha independentes.

 function a(b){if(c){d}else{e}} //ok function a(b){if(c)d;else e} //ok 

É claro que você precisa replace a chave de fechamento por um ponto-e-vírgula, se não for seguida por outra chave de fechamento.

Uma function não deve terminar em uma vírgula.

 var a,b=function()c; //ok *but not in Chrome var b=function()c,a; //error 

Testado no Chrome e no FF.

Eu encontrei esta resposta pesquisando sobre uma experiência semelhante, então decidi responder com a minha experiência.

As instruções sem suporte funcionam na maioria dos navegadores, no entanto, eu testei que os methods sem brackets na verdade não funcionam em algum navegador.

A partir de 26 de fevereiro de 2018, esta declaração funciona em Pale Moon, mas não no Google Chrome.

 function foo() return bar; 

Às vezes eles parecem ser necessários! Eu não pude acreditar em mim mesmo, mas ontem me ocorreu em uma session do Firebug (recente Firefox 22.0) que

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

executado fazer alguma coisa apesar de my.condition.key era verdade . Adicionando chaves:

 if (! my.condition.var) { do something; } 

fixo isso importa. Há myriards de exemplos onde aparentemente trabalha sem as chaves, mas neste caso definitivamente não fez.

Pessoas que tendem a colocar mais de uma frase em uma linha devem sempre usar chaves, é claro, porque coisas como

 if (condition) do something; do something else; 

são difíceis de encontrar.

Gostaria apenas de observar que você também pode deixar as chaves do outro. Como visto neste artigo por John Resig .

 if(2 == 1){ if(1 == 2){ console.log("We will never get here") } } else console.log("We will get here") 

Existem muitos problemas no javascript. Dê uma olhada no arquiteto de JavaScript Douglas Crockford falando sobre isso A declaração if parece estar bem, mas a declaração de retorno pode introduzir um problema.

 return { ok:false; } //silent error (return undefined) return{ ok:true; } //works well in javascript 

Existe uma maneira de obter múltiplas chaves não-encaracoladas se as declarações … (Uau que inglês ..) mas é meio tedius:

 if(true) funcName(); else return null; function funcName(){ //Do Stuff Here... } 

O nível de recuo inicial de uma instrução deve ser igual ao número de chaves abertas acima dela. (excluindo chaves citadas ou comentadas ou aquelas em diretivas de pré-processador)

Caso contrário, K & R seria um bom estilo de recuo. Para corrigir seu estilo, recomendo colocar instruções simples e curtas em uma linha.

 if (foo) bar(); // I like this. It's also consistent with Python FWIW 

ao invés de

 if (foo) bar(); // not so good 

Se eu estivesse escrevendo um editor, faria seu botão de formatação automática chupar a barra até a mesma linha de foo, e faria com que ele inserisse chaves ao redor da barra se você pressionasse o retorno antes desse modo:

 if (foo) { bar(); // better } 

Então é fácil e consistente adicionar novas instruções acima ou abaixo da barra dentro do corpo da instrução if

 if (foo) { bar(); // consistent baz(); // easy to read and maintain } 

Sempre achei que

 if(valid) return; 

é mais fácil para os meus olhos do que

 if(valid) { return; } 

também condicional, como

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

são mais fáceis de ler (minha opinião pessoal) em vez de

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

mas eu acho que se resume ao estilo de codificação

Não está respondendo a pergunta diretamente, mas abaixo está uma syntax curta sobre se a condição em uma linha

Ex:

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

Pode ser escrito assim:

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