Pergunta

No caso de idiomas que oferecem suporte a decisão e a ação, sem os colchetes, como o exemplo a seguir:

if (var == true)
    doSomething();

Qual é a melhor maneira de escrever isso?Devem sempre ser usados parênteses, ou deve-se a sua utilização ser deixado como uma preferência do desenvolvedor individual?Além disso, esta prática depende do tamanho do bloco de código, como no exemplo a seguir:

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}
Foi útil?

Solução

Não há realmente uma resposta certa.Isso é o que padrões de codificação dentro da empresa são destinados.Se você pode mantê-lo consistente em toda a empresa, então ele será de fácil leitura.Eu, pessoalmente, gosto de

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

mas esta é uma guerra santa.

Outras dicas

Eu recomendo

if(a==b)
{
    doSomething();
}

porque acho que é muito mais fácil fazê-lo à frente do que para tentar lembre-se de adicionar as chaves quando eu adicionar uma segunda instrução para o sucesso condição...

if(a==b)
    doSomething();
    doSomethingElse();

é muito diferente

if(a==b)
{
    doSomething();
    doSomethingElse();
}

ver Joel artigo para obter mais detalhes

Eu tendem a usar chaves em todos os momentos.Você pode obter alguns bugs sutis onde você começou com algo como:

if(something)
 DoOneThing();
else
  DoItDifferently();

e, em seguida, decidir adicionar outra operação para o else cláusula e se esqueça de envolvê-la entre chaves:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

AlwaysGetsCalled() será sempre chamado, e se você está sentado lá às 3h da madrugada perguntando por que o seu código está se comportando todo estranho, algo como o que poderia escapar de você por algum tempo.Só por esse motivo, eu sempre utilizar chaves.

A minha preferência é para ser consistente, por exemplo, se você usar parênteses em um bloco, use colchetes todo, mesmo com apenas uma instrução:

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Mas se você tiver apenas um monte de piadas:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

Parece mais limpa (se você não mente que o método fictício nomes ;) dessa forma, mas isso é só comigo.

Isto também se aplica a construções de loop e o como:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

Você também deve considerar que esta é uma convenção que pode ser mais adequado para .NET (observe que o Java peepz gostaria de ter seu primeiro chaveta na mesma linha que o caso).

Giz esta falta de experiência, mas durante os sete anos de mandato como um código de macaco eu nunca na verdade, visto alguém cometer o erro de não adicionar chaves ao adicionar código para um bloco que não tem chaves.Essa é precisamente a zero vezes.

E antes que o wisecrackers chegar a ele, não, a razão não era "todo mundo sempre usa as chaves".

Então, uma pergunta sincera-eu realmente gostaria de obter respostas, em vez de apenas downvotes:não que alguma vez realmente acontecer?

(Edição:Eu já ouvi o suficiente terceirização de histórias de horror para esclarecer um pouco:ele nunca realmente acontecer competente programadores?)

Isso realmente não importa, desde que você está coerente com ela.

Não parece haver uma tendência para a procura de semelhança dentro de uma única instrução, i.é.se há colchetes em um ramo, há suportes em todos os lugares.O kernel do Linux padrões de codificação, para um, o mandato que.

Eu fortemente advogado sempre usando chaves, mesmo quando eles são opcionais.Por quê?Levar este pedaço de código em C++:

if (var == 1)
  doSomething();
doSomethingElse();

Agora, vem alguém que não está realmente prestando atenção suficiente e decide que algo extra que precisa acontecer if (var == 1), então eles fazem isso:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

É tudo ainda lindamente recuada, mas ele não vai fazer o que pretendia.

Sempre usando o aparelho, você é mais provável para evitar este tipo de erro.

Eu personnally lado com McConnell explicação do Código Completo.

Use-os sempre que pode.Eles melhoram a legibilidade do seu código e remover os poucos e escassos confusões que possam ocorrer.

Há uma coisa que é mais importante, no entanto....Consistência.Que estilo usar,certifique-se de que você sempre fazê-lo da mesma forma.

Começar a escrever coisas como:


If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

Você é obrigado a terminar acima de olhar para um estranho bug onde o compilador não vai entender o que você estava tentando fazer, e que vai ser difícil de encontrar.

Basicamente encontrar o que você está confortável escrevendo sempre e cumpri-lo.Eu acredito em usando o bloco de delimeters('{', '}') tanto quanto possível, é o caminho a percorrer.

Eu não quero começar uma pergunta dentro de outro, mas há algo relacionado a isso que eu quero falar para obter a sua saúde mental e sucos indo.Um a decisão de utilizar os parênteses tem sido feito.Onde colocar o colchete de abertura?Na mesma linha como a instrução ou para baixo.Recuado parênteses ou não?


If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

Por favor, não responda a este, pois esta seria uma nova pergunta.Se eu vejo um interesse neste, vou abrir uma nova pergunta a sua entrada.

Eu sempre usei suportes em todos os momentos, exceto para o caso de onde eu sou a verificação de uma variável NULL antes de libertá-lo, como é necessário em C

Nesse caso, certifique-se de que é claro que é uma única instrução mantendo tudo em uma linha, como este:

if (aString) free(aString);

Não há maneira certa ou errada para escrever a declaração acima.Há uma abundância de aceite de codificação estilos.No entanto, para mim, eu prefiro manter o estilo de codificação consiste durante todo o projeto.ou seja.Se o projeto estiver usando K&R do estilo, você deve usar K&R.

Ruby bem elimina um problema em discussão.O padrão para um one-liner é:

do_something if (a == b)

e para uma multi-linha:

if (a == b)
  do_something
  do_something_else
end

Isso permite que concisa de uma linha de declarações, mas o obriga a reorganizar a instrução se você vai partir de um único multi-linha.

Este não é (ainda) disponível em Java, nem em muitas outras línguas, AFAIK.

Como outros já mencionados, fazendo uma instrução if em duas linhas sem chaves pode levar a confusão:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

assim que eu colocá-lo em uma única linha, se eu posso fazer isso, sem ferir a legibilidade:

if (a == b) DoSomething();

e em todas as outras vezes eu uso aparelho nos dentes.

O operador ternário é um pouco diferente.A maioria das vezes eu faço-os em uma linha:

var c = (a == b) ? DoSomething() : DoSomethingElse();

mas, às vezes, as instruções de chamadas de função aninhada, ou expressões lambda que fazer uma linha de instrução de difícil analisar visualmente, por isso, prefiro algo como isto:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Ainda mais concisa do que um if/else bloco, mas fácil de ver o que está acontecendo.

Sol Código de Convenções para a Linguagem de programação Java tem este para dizer:

O if-else classe de instruções deve ter a seguinte forma:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

O nosso patrão nos faz colocar { } depois de uma decisão de instrução, não importa o que, mesmo se tratando de uma única instrução.É realmente irritante para adicionar duas linhas extras.A única exceção é o operador ternário.

Eu acho que é uma coisa boa que eu tenho o meu código de monitor na orientação retrato em 1200 x 1600.

Eu prefiro

if (cond)
   {
   //statement
   }

mesmo com apenas uma única instrução.Se você fosse escrever algo assim, não tinha dúvidas de que ele trabalhou, e nunca planejou outro programador sempre olhando o código, vá em frente e use qualquer que seja o formato que você quiser.Mas, o que o extra bracketing realmente custar?Menos tempo no decurso de um ano do que é preciso para escrever este post.

Sim, eu gostaria de recuo minha suportes ao nível do bloco, também.

Python é nice, em que o recuo define o bloco.A questão é discutível em uma linguagem como essa.

Eu tendo a concordar com o Joel Spolsky, que com esse artigo (Fazendo De Errado Código Olhar Errado) com o seguinte código de exemplo :

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

Foo é agora unconditionnal.O que é muito ruim!

Eu sempre uso de suportes para a tomada de declarações.Ele ajuda a capacidade de manutenção do código e torna o código menos propensas a erro.

Eu uso as chaves ao redor de cada instrução se e somente se pelo menos um deles exige isso.

Em Perl, se você está fazendo um teste simples, em algum momento você vai escrever nesse formulário:

do_something if condition;

do_something unless condition;

Que pode ser muito útil para verificar os argumentos no início de uma sub-rotina.

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

A regra de ouro é que, quando se trabalha em um projeto existente, siga os padrões de codificação.

Quando eu estou em casa, eu tenho duas formas.

O primeiro é a única linha:

if (condition) doThis();

e o segundo é para múltiplas linhas:

if (condition) {
   doThis();
}

Eu costumava acompanhar o "use as chaves sempre" linha como um apparatchik.No entanto, modifiquei meu estilo para permitir omitindo-os em uma única linha de expressões condicionais:

if(!ok)return;

Para quaisquer várias instruções de cenário que eu ainda sou da opinião de que chaves deve ser obrigatória:

if(!ok){

    do();

    that();

    thing();
}
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top