Na maioria das vezes, essa é uma preferência pessoal, mas há algumas coisas a considerar.
Possíveis erros
Embora se possa argumentar que os erros causados por esquecer de adicionar-in chaves são raros, pelo que tenho visto que eles não acontecem de vez em quando (não esquecer a famosa Goto IOS falhar bug). Portanto, acho que isso deve ser um fator ao considerar seu estilo de código (algumas ferramentas alertam sobre indentação enganosa , portanto depende da sua cadeia de ferramentas) .
Código válido (que pode parecer um bug)
Mesmo assumindo que o seu projeto não sofrem de tais erros, ao ler o código que você pode ver alguns blocos de código que se parecem com eles poderia ser erros - mas não são, tendo alguns dos seus ciclos mentais.
Começamos com:
if (foo)
bar();
Um desenvolvedor adiciona um comentário útil.
if (foo)
// At this point we know foo is valid.
bar();
Mais tarde, um desenvolvedor se expande.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Ou adiciona um bloco aninhado:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Ou usa uma macro:
if (foo)
SOME_MACRO();
"... Como as macros podem definir várias linhas de código, a macro usa do {...} while (0)para várias linhas? Deve ser porque está no nosso guia de estilo, mas é melhor verificar apenas por precaução!"
Os exemplos acima são todos códigos válidos; no entanto, quanto mais conteúdo no bloco de códigos, mais você precisa ler para garantir que não haja erros.
Talvez o seu estilo de código defina que os blocos de várias linhas exigem uma chave (não importa o que aconteça, mesmo que não sejam códigos) , mas vi esses tipos de comentários sendo adicionados ao código de produção. Quando você o lê, há uma pequena dúvida de que quem quer que tenha editado essas linhas pela última vez se esqueceu de adicionar uma chave, às vezes sinto que a necessidade de verificar duas vezes está funcionando conforme o esperado (especialmente ao investigar um bug nesta área do código) .
Diff Noise
Uma razão prática para usar chaves para linhas únicas é reduzir o ruído diferencial .
Ou seja, mudando:
if (foo)
bar();
Para:
if (foo) {
bar();
baz();
}
... faz com que a linha condicional apareça em um diff como sendo alterada, isso adiciona uma sobrecarga pequena, mas desnecessária.
- as linhas aparecem como sendo alteradas nas revisões de código; se suas ferramentas diferentes são baseadas em palavras, é fácil ver que apenas a chave mudou, mas leva mais tempo para verificar se a linha não foi alterada.
Dito isto, nem todas as ferramentas suportam diffing baseado em palavras, diff (svn, git, hg ... etc) será exibido como se toda a linha tivesse mudado, mesmo com ferramentas sofisticadas, às vezes você pode precisar olhar rapidamente sobre uma linha simples diff baseado em para ver o que mudou.
- As ferramentas de anotação (como
git blame) mostrarão a linha como sendo alterada, tornando o rastreamento da origem de uma linha mais uma etapa para encontrar a mudança real .
Ambos são pequenos e dependem de quanto tempo você gasta na revisão ou rastreamento de código que confirma as linhas de código alteradas.
Um inconveniente mais tangível de ter alterações de linhas extras em um diff, é mais provável que alterações no código causem conflitos que se fundem e precisam ser resolvidos manualmente .
Há uma exceção a isso, para bases de código que possuem {sua própria linha - não é um problema.
O argumento diff noise não se aplica se você escrever neste estilo:
if (foo)
{
bar();
baz();
}
No entanto, essa não é uma convenção tão comum, portanto contribuindo principalmente para a resposta de completude (não sugerindo que os projetos usem esse estilo) .
