Qual é o melhor estilo para uma única decisão e ação declarações?
-
08-06-2019 - |
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);
}
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();
}