A declaração if com parênteses é desaprovada, mas ainda é um estilo ruim se o seu IDE estiver equipado para isso?

4

Este tipo de declaração condicional é geralmente desaprovado

if(condition)
  statement;

porque se você adicionar outra instrução, como esta

if(condition)
  statement;
  statement;

dá a impressão de que o segundo statement é parte do bloco if quando não é.

Dito isto, o meu IDE faz recuo automático, o que eu acho que torna este problema discutível. Além disso, quando eu quero adicionar outra instrução, ela automaticamente faz a conclusão do colchete - o que torna a questão sobre ter que adicionar colchetes manualmente quando você quer adicionar outra instrução discutível.

Existe alguma razão pela qual isso ainda seria um estilo ruim?

    
por Peter Olson 25.04.2012 / 04:57
fonte

6 respostas

27

Sim, porque nem todos da sua equipe podem estar usando esse IDE específico. Em geral, ainda é bastante perigoso, já que a maioria dos IDEs / editores não tem essa funcionalidade, então ainda pode deixar bugs entrarem.

Além disso, muitas pessoas preferem os colchetes para fins de legibilidade, pois deixa mais claro que determinado código está associado a uma instrução if.

    
por 25.04.2012 / 04:59
fonte
16

Tudo bem, eu vou ser o único a declarar o não dito. Se a omissão dos parênteses fosse uma ofensa tão séria, ela apareceria com -Wall , e nenhum dos idiomas mais recentes permitiria que você fizesse isso. Não é nem de perto uma preferência universal, e muitas pessoas até mesmo removem os colchetes do código existente porque ele remove a desordem e esclarece que você pretende incluir apenas uma instrução. É um erro de novato porque o código não passa nos testes básicos e, na minha experiência, o seguinte erro é mais comum entre os novatos:

if (condition);
{
    statement;
}

Provavelmente porque o autoindent não detecta esse bug, mas irá capturar o mencionado como o motivo para incluir os colchetes supérfluos. Autoindent tem sido uma característica do editor do programador cada por décadas, e se você não usá-lo, você merece ser frustrado por erros de sintaxe estúpidos.

    
por 25.04.2012 / 05:56
fonte
5

A legibilidade e a facilidade de manutenção são, na maioria das circunstâncias, os dois atributos mais importantes de qualquer parte do código. Usar a lógica condicional sem chaves reduz a legibilidade, e é por isso que ela é considerada um estilo ruim. Ter um IDE chique não transforma o estilo ruim em bom estilo. Não faça isso.

    
por 25.04.2012 / 08:05
fonte
5

O uso ou não da chave é uma preferência pessoal (e / ou de equipe). Há profissionais para contras sobre cada um. A razão para escolher lados é ser consistente e produzir código que seja mais fácil de entender e manter (e por "você" quero dizer "sua equipe" se você estiver trabalhando em um ambiente de equipe).

Sua pergunta parece não ser se uma é melhor que a outra, mas se você deve deixar sua IDE lhe dizer o que é melhor. E para essa pergunta eu digo um retumbante NO . Escolha suas convenções de codificação com base no que você acha melhor, ou sua equipe, se você estiver trabalhando em uma equipe.

    
por 25.04.2012 / 13:08
fonte
2

Uma das coisas boas sobre o uso de delimitadores de bloco (ou seja, chaves em linguagem C-Styled, ou begin / end em linguagens semelhantes a Pascal) é que quando usados isoladamente e em uma linha separada, eles introduzem espaço em branco adicional seu código. Agora, sem entrar em uma batalha sobre as escolhas de estilo suspenso x inline-cinta, o ponto é simplesmente que, na medida em que o compilador não se importa, adicionar um pouco de espaço extra ajuda a melhorar a legibilidade (particularmente para aqueles com olhos que não são tão jovens quanto costumavam ser !!). É o mesmo truque que você usa quando cria um currículo. Mais espaço em branco torna as coisas melhores por si mesmas.

As outras razões para usar delimitadores de bloco é deixar absolutamente claro onde algo começa e termina. Claro, você pode fazer o seguinte:

DoTheFirstThing();
if (condition)
DoSomething();
DoSomethingElse();

No entanto, ao ler o código, os olhos podem facilmente passar pelo código e você acaba fazendo suposições sobre o que ocorreu como parte da instrução if. Considerando que se você fosse adicionar um par de chaves:

DoTheFirstThing();
if (condition)
{
DoSomething();
}
DoSomethingElse();

você está deixando mais claro onde o bloco if realmente começa e termina. É claro que, se você é pedante sobre seu recuo, pode argumentar que um simples recuo é suficiente. Claro, se você está acostumado a usar uma linguagem como a Python, pode estar acostumado a prestar atenção especial à sua indentação, mas isso realmente torna as coisas muito mais claras? Vamos dar mais alguns exemplos. Decida qual declaração se destaca como a mais clara quando você dá uma rápida olhada no seguinte:

DoTheFirstThing();
if (condition)
    DoSomething();
DoSomethingElse();
DoTheSecondThing();
if (condition)
{
    DoSomething();
}
DoSomethingElse();

Agora faça o mesmo que no exemplo anterior, com isto:

DoTheFirstThing();
if (condition)
    DoSomething();
DoSomethingElse();
DoTheFirstThing();

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Dos dois exemplos, a última declaração if com a maior quantidade de espaço em branco se destaca, e o código parece mais claro, mesmo sendo exatamente o mesmo.

Então, para realmente responder a pergunta do OP, é Bad para agrupar as coisas e evitar colchetes? Minha resposta é não, e acho que chamá-lo de ruim ou ruim, ou algum outro negativo, é colocá-lo um pouco strong. O compilador realmente não se importa, e o código funcionará exatamente da mesma maneira. No entanto, é certamente mais legível se você adicionar as chaves e mostra o objetivo da instrução If mais claramente. Mais importante talvez, é que isso mostra que você está tomando um pouco de cuidado para garantir a qualidade do seu trabalho se destaca. É como a diferença entre pintar rapidamente uma parede com um pincel largo uma vez, ou usar um rolo e aplicar cuidadosamente duas demãos de tinta. Assim como é importante olhar para o acabamento de um trabalho de pintura, também o cuidado extra com seu código mostra que você está disposto a reservar tempo para garantir que os outros não terão dificuldade em ler através do seu trabalho. Isso se paga quando você precisa revisitar o código meses ou mesmo anos depois, ou quando alguém precisa dar suporte a seu código depois que você terminar.

O código cuidadosamente escrito, limpo e legível inspira confiança no código, enquanto o código bagunçado geralmente inspira uma atitude horrível e muito difícil de trabalhar com em relação ao código. A atenção aos detalhes mostra uma diferença entre o profissional cuidadoso e o programador menos cuidadoso. Ele inspira confiança em seu trabalho e é um prazer trabalhar com ele.

    
por 25.04.2012 / 06:01
fonte
1

A qualidade do código é independente do IDE usado para gerá-lo (tempo passado!). O IDE que será usado para alterá-lo pode aliviar alguns problemas de código. Mas isso é no futuro. Você deve lutar pela qualidade agora.

Como você pode ver nas outras respostas, algumas pessoas não consideram esse estilo ruim. Mas suponho que a maioria concordaria que misturar dois estilos vale muito mais do que < qualquer estilo de codificação que você despreza vai aqui > Então, se você está em uma equipe ou trabalha com uma base de código consistente existente, atenha-se às regras. IMHO essa é a coisa profissional a fazer.

    
por 25.04.2012 / 09:22
fonte