Formatação de if

Question

Isto não é uma guerra santa, esta não é uma questão de "o que é melhor".

Quais são as vantagens de utilizar o seguinte formato para única instrução se os blocos.

if (x) print "x is true";

if(x) 
    print "x is true";

Ao contrário

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

Se você formatar suas ifs única declaração sem colchetes ou conhece um programador que faz, o que o levou /-los a adotar esse estilo em primeiro lugar? Estou especialmente interessado em que beneficia esta trouxe-o.

Atualizar :. Como a resposta mais popular ignora a questão real (mesmo que apresenta o conselho mais sensato), aqui está um resumo dos prós suporte-less

1. Compacidade
2. Mais legível para alguns
3. Suportes de invocação escopo, que tem uma sobrecarga teórica em alguns casos

Answer 1

Eu acho isso:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

melhor do que este:

if( true )
    DoSomething();
else
    DoSomethingElse();

Desta forma, se eu (ou alguém) volta a este código depois de adicionar mais código para um dos ramos, que não terá que se preocupar em cercar o código no aparelho. Nossos olhos vai ver visualmente o recuo como pistas para o que estamos tentando fazer, mas a maioria das línguas não vai.

Answer 2

Eu não gosto fortemente qualquer estilo que coloca o caso do teste e do corpo na mesma linha.

Isto é porque partilha a linha torna impossível definir um ponto de interrupção no caso do corpo de muitas depuradores porque breakpoints são tipicamente número da linha base.

Answer 3

Sempre usando chaves é uma boa idéia, mas a resposta padrão que é sempre dado "e se alguém adiciona uma linha de código e se esquece de adicionar as chaves?" é uma razão bastante fraca.

Há um bug sutil que pode ser introduzida por não ter as chaves desde o início. Aconteceu-me algumas vezes e eu já vi isso acontecer com outros programadores.

Ele começa, inocentemente, com um simples if.

if (condition)
    do_something();
else
    do_something_else();

Que é tudo muito bem.

Em seguida, alguém vem e acrescenta uma outra condição para o caso. Eles não podem adicioná-lo usando && ao se a própria declaração porque a lógica seria incorreto, então eles adicionar outro caso. Temos agora:

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

Você vê o problema? Pode olhar direito, mas o compilador vê de forma diferente. Vê-lo assim:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

O que significa algo completamente diferente. O compilador não se preocupa com a formatação. A outra vai com o mais próximo se. Os humanos, por outro lado, contar com a formatação e pode facilmente perder o problema.

Answer 4

Eu sempre uso

if(x) 
{
    print "x is true";    
}

deixando de fora as chaves pode resultar em alguém manter o código por engano pensar que eles estão adicionando a cláusula if se adicionar uma linha após a linha atual.

Answer 5

Eu uso

if (x)
{
    DoSomething();
}

para várias linhas, mas eu prefiro Bracketless forros:

if (x)
   DoSomething();
else
   DoSomethingElse();

I encontrar os suportes externos visualmente ofensivo, e eu nunca fiz um dos erros acima mencionados não adicionando colchetes ao adicionar outra declaração.

Answer 6

if
{
// code
}
else 
{
// else code
}

Porque eu gosto quando os blocos de código linha para cima (incluindo as chaves).

Answer 7

Se o código I:

if(x) 
    print "x is true";

e 6 meses mais tarde precisar adicionar uma nova linha, a presença de chaves torna muito menos provável que eu vou digitar

if(x) 
    print "x is true";
    print "x is still true";

o que resultaria em um erro lógico, contra:

if(x) { 
    print "x is true";
    print "x is still true";
}

chaves Assim encaracolados fazer tais erros lógicos mais fácil de ler e evitar, eu acho.

Answer 8

Como Matt (3 acima), eu prefiro:

if (x)
{
    ...statement1
    ...statement2
}

e

if (x)
    ...statement
else
    ...statement

Eu acho que é muito estranho pensar que alguém pode vir mais tarde e não percebem que têm de adicionar as chaves para formar uma multi-linha se bloco. Se isso está além de suas capacidades, gostaria de saber o que as outras coisas são!

Answer 9

declaração única se blocos que faltam chaves:

Pros:

• menos caracteres
• aparência mais limpa

Contras:

• uniformidade: nem todos se os blocos têm a mesma aparência
• potencial de erros ao adicionar declarações ao bloco:. Um usuário pode esquecer de adicionar as chaves e a nova declaração seria, sem ser abrangidos pelo if

Como em:

if(x) 
    print "x is true";
    print "something else";

Answer 10

I tendem apenas a única linha quando eu estou testando para condições de quebra no início de uma função, porque eu gosto de manter esse código como simples e organizada possível

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

Além disso, se eu acho que eu quero evitar chaves e in-line um se o código cláusula, eu posso única linha-los, apenas por isso é óbvio para qualquer adição de novas linhas para o caso que colchetes precisam ser adicionado

Answer 11

Eu uso

if (cond) {
  ...
} else {
  ...
}

• Tudo deve sempre ter chaves. Mesmo que agora eu só tenho uma linha no bloco if, fiz adicionar mais tarde.
• Não colocar as chaves em suas próprias linhas porque é inútil desperdício de espaço.
• Eu raramente colocar o bloco na mesma linha que o condicional para facilitar a leitura.

Answer 12

Joel Spolsky escreveu um bom artigo: Fazendo errado Código olhar errado

Ele aborda especificamente esta questão ...

if (i != 0)  
    foo(i);

Neste caso, o código é 100% correto; está em conformidade com a maioria das convenções de codificação e não há nada de errado com isso, mas o fato de que a única declaração corpo do ifstatement não é colocado entre chaves podem ser incomodando, porque você pode estar pensando no traseira de sua cabeça, meu Deus, alguém pode inserir outra linha de código há

if (i != 0)
    bar(i);
    foo(i);

... e esquecer de adicionar as chaves, e assim, acidentalmente fazer foo (i) incondicional! Então, quando você vê blocos de código que não estão em chaves, você pode sentir apenas uma pequena, pequenino, soupçon de impureza que faz você inquieto.

Ele sugere que você ...

... deliberadamente arquiteto seu código de tal forma que seu nariz para uncleanliness faz seu código mais provável que seja correto.

Answer 13

Eu não gosto de usar chaves quando eles não são necessários. Eu sinto que incha o número de linhas em um método e torna ilegível. Então, eu quase sempre ir para o seguinte:

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

E assim por diante. Se alguém precisa de adicionar outra declaração, em seguida, ele pode apenas adicionar as chaves. Mesmo se você não tem R # ou algo semelhante que é um pequeno negócio.

Ainda assim, existem alguns casos que eu iria usar chaves, mesmo se houver apenas uma linha na declaração, e isso é se a linha é especialmente longa, ou se eu precisar de comentários dentro do que 'se'. Basicamente, eu só usar o que parece mais agradável para os olhos para olhar.

Answer 14

Whitespace é seu amigo ....

Mas, novamente, eu como:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 15

Sério, quando foi a última vez que você teve um erro em qualquer lugar do código que foi motivo alguém fez:

if (a)
  foo();
  bar();

Sim, nunca mais ... * A única real 'pro' aqui é apenas para combinar com o estilo do código circundante e deixar as batalhas estéticas para as crianças que só saí dessa faculdade.

* (ressalva sendo quando foo (); bar (); era uma expansão de macro, mas isso é um problema w / macros, não chaves w / ifs.)

Answer 16

if (x) {
    print "x is true";    
}
else {
    do something else;
}

Eu sempre digitar chaves. É apenas um bom hábito. Comparado com o pensamento, a digitação não é "trabalho".

Observe o espaço antes da condicional. Que ajuda a não parecer uma chamada de método.

Answer 17

Outra forma seria a de escrever:

(a==b) ? printf("yup true") : printf("nop false");

Esta será prático se você quiser armazenar um valor comparando uma condição simples, assim:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 18

if (x)
{
    print "x is true";
}

Abertura e chave de fechamento na mesma coluna faz com que seja fácil de encontrar chaves incompatíveis, e isola visualmente o bloco. Abrindo cinta na mesma coluna que "se" faz com que seja fácil ver que o bloco é parte de uma condicional. O espaço em branco extra em torno do bloco criado pelas linhas contendo apenas chaves facilita para buscá-lo para fora a estrutura lógica quando skimreading código. Sempre usando explicitamente chaves ajuda a problemas evitar quando pessoas editar o código mais tarde e descaracterizou que declarações fazem parte da condicional e quais não são -. Recuo pode não coincidir com a realidade, mas que está sendo colocado entre chaves sempre será

Answer 19

Sobre a única vez no-órtese parece ser aceite é quando o parâmetro verificando as variáveis ??no início de um método:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

A única vantagem é compacidade. O programador não tem de percorrer throught desnecessário {} é quando é óbvio que:

• as saídas método em qualquer verdadeiro ramo
• é bastante óbvio estes são todos os 1-liners

Dito isso, eu sempre {} para a lógica do programa pelas razões apresentadas por outros. Quando você deixa cair as chaves É muito fácil mentalmente cinta quando ele não está lá e introduzir defeitos de código sutis.

Answer 20

H8ers ser condenado Eu não sou realmente um para regras dogmáticas. Em determinadas situações, eu vou realmente favorecer compacidade se ele não funcionar sobre uma determinada largura, por exemplo:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

Isto é muito mais legível para mim do que:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

Isto tem a vantagem de incentivar as pessoas a lógica abstrata em métodos (como eu fiz), em vez de manter agregando mais lógica em aninhados blocos if-else. Ele também leva até três linhas, em vez de sete, o que pode torná-lo possível para não ter de se deslocar para ver vários métodos, ou outro código.

Answer 21

Eu prefiro o estilo colchetes, principalmente porque dá aos olhos de um ponto de partida e parada clara. Ela torna mais fácil para ver o que realmente está contido na declaração, e que na verdade é uma instrução if. Uma pequena coisa, talvez, mas é por isso que eu usá-lo.

Answer 22

desde que seja consistente entre a equipe em que trabalha, então não importa muito

que todo mundo faz a mesma é a principal coisa

Answer 23

Bracketing de seu one-liner if tem a vantagem de tomada de sane considerável de protegê-lo de dores de cabeça, se, em algum momento posterior, você (ou outros programadores manter ou alterar o seu código) necessidade de adicionar declarações a uma parte da que condicional bloco.

Answer 24

Se você fizer algo como isto:

if(x)
{
    somecode;
}
else
{
    morecode;
}

Isso funciona melhor para controle de origem e directivas de pré-processador no código que vive um longo tempo. É mais fácil adicionar um #if ou assim sem inadvertidamente quebrar a declaração ou ter que adicionar linhas extras.

é um pouco estranho para se acostumar, mas funciona muito bem depois de um tempo.

Answer 25

Se é uma linha de if (e, opcionalmente, uma linha de outra pessoa) Eu prefiro não usar os suportes. É mais legível e conciso. Eu digo que eu prefiro, porque ela é puramente uma questão de preferência. Embora eu acho que a tentativa de impor um padrão que você deve sempre usar as chaves é meio bobo.

Se você tem que se preocupar com alguém adicionando outra linha para o corpo do if e não adicionando as chaves (só então necessário), eu acho que você tem problemas maiores do que os padrões sub-bizantino de codificação.

Answer 26

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

Eu nunca usar espaços em branco supérfluo além abas, mas sempre incluindo os suportes poupa montes de tempo.

Answer 27

Eu não gosto de fechar chaves na mesma linha com a palavra-chave a seguir:

if (x) {
    print "x is true";    
} else {
    do something else;
}

Isso torna mais difícil para remover / comment-out apenas a cláusula else. Colocando a palavra-chave acompanhamento na próxima linha, eu posso aproveitar, por exemplo, os editores que me permitem selecionar um intervalo de linhas, e comentário / uncomment-los todos de uma vez.

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

Answer 28

Eu sempre prefiro este:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

Mas sempre dependem do idioma e as ações que você está fazendo. Às vezes eu gosto de colocar cintas e às vezes não. Dependem do código, mas i de codificação como um tem que escrever uma vez, re-escrever dez vezes, e ler cem vezes; assim, apenas fazê-lo como você quer e como você quer ler e entender mais rapidamente

Answer 29

Não importa o que, esta é a maneira que eu vou! Parece o melhor.

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 30

Se você é curioso o que os nomes para os vários código de estilos de formatação são, Wikipedia tem um artigo sobre Estilos travessão .