Declaração única se chaves - ou não? [fechadas]

Qual é o melhor / mais aceito?

Este:

if(condition)
{
  statement;
}

Ou:

if(condition)
  statement;

Eu tendem a preferir o primeiro, porque acho que fica mais fácil dizer o que realmente pertence ao bloco if, evita que outras pessoas adicionem o aparelho mais tarde (ou criem um bug esquecendo-se de) e faz todas as suas declarações if uniforme em vez de alguns com aparelho e outros sem. O segundo, no entanto, ainda é sintaticamente correto e definitivamente mais compacto. Estou curioso para ver o que é mais geralmente preferido pelos outros.

O primeiro é melhor porque o segundo é propenso a erros. Por exemplo, digamos que você esteja comentando temporariamente o código para depurar algo:

if(condition) 
//      statement;
otherStatement;

Ou adicionando código com pressa:

if(condition) 
    statement;
    otherStatement;

Isso é obviamente ruim. Por outro lado, o primeiro parece muito detalhado às vezes. Portanto, prefiro colocar tudo em uma linha se for suficientemente curto e simples:

if(condition) statement;

Isso reduz o ruído sintático e, ao mesmo tempo, faz com que a construção pareça fazer o que realmente faz, tornando-a menos propensa a erros. Desde que essa sintaxe seja usada apenas para condições e instruções muito simples e curtas, acho perfeitamente legível.

Eu sempre uso colchetes apenas para estar seguro.

Tudo bem quando você escreve, mas sabe que alguém virá no futuro e inserirá outra declaração sem colocar colchetes.

Prefiro a versão sem aparelho, sempre que possível.

A explicação a seguir é longa. Por favor, tenha paciência comigo. Vou dar uma razão convincente para eu preferir esse estilo. Também explicarei por que acho que o contra-argumento usual não se sustenta.

Linhas (quase) vazias são um desperdício

A razão para isso é que a chave de fechamento requer uma linha extra de código - e a chave de abertura, dependendo do estilo. ^{1 1}

Este é um grande negócio? Superficialmente, não. Afinal, a maioria das pessoas também coloca linhas vazias em seu código para separar blocos logicamente ligeiramente independentes, o que melhora bastante a legibilidade.

No entanto, detesto desperdiçar espaço vertical. Na verdade, os monitores modernos têm amplo espaço horizontal. Mas o espaço vertical ainda é muito, muito limitado (a menos que você use um monitor na posição vertical, o que não é incomum). Esse espaço vertical limitado é um problema: é amplamente reconhecido que os métodos individuais devem ser tão curtos quanto possível e que as chaves correspondentes (ou outros delimitadores de bloco) não devem ter mais que uma altura de tela na diferença, para que você possa ver o bloco inteiro sem rolagem.

Esse é um problema fundamental : depois que você não consegue mais ver o bloco inteiro na tela, fica difícil entender.

Como conseqüência, detesto linhas vazias redundantes. Onde linhas vazias únicas são cruciais para delimitar blocos independentes (basta olhar para a aparência visual deste texto), linhas vazias consecutivas são um estilo muito ruim no meu livro (e, na minha experiência, elas geralmente são um sinal de programadores iniciantes).

Da mesma forma, linhas que simplesmente se sustentam e que podem ser economizadas devem ser. Um bloco de instrução única que é delimitado por chaves desperdiça uma a duas linhas. Com apenas 50 linhas ish por altura da tela, isso é perceptível.

Omitir aparelho não faz mal nenhum

Há apenas um argumento contra a omissão de chaves: que alguém mais tarde adicione outra declaração ao bloco em questão e esqueça de adicioná-las, alterando inadvertidamente a semântica do código.

Isso seria realmente um grande negócio.

Mas na minha experiência, não é. Sou um programador desleixado; e, no entanto, em minha década de experiência em programação, posso dizer honestamente que nunca esqueci de adicionar chaves ao adicionar uma declaração extra a um bloco singleton.

Até acho implausível que esse seja um erro comum: os blocos são uma parte fundamental da programação. A resolução e o escopo no nível do bloco são um processo mental automático e arraigado para os programadores. O cérebro simplesmente faz isso (caso contrário, raciocinar sobre programação seria muito mais difícil). Não há esforço mental adicional necessário para lembrar de colocar os aparelhos: o programador também se lembra de recuar a declaração recém-adicionada corretamente, afinal; então o programador já processou mentalmente que um bloco está envolvido.

Agora, eu estou não dizer que omitindo chaves não causar erros. O que estou dizendo é que não temos evidências de um jeito ou de outro. Simplesmente não sabemos se isso causa danos.

Então, até que alguém possa me mostrar dados concretos, coletados de experimentos científicos, demonstrando que isso é realmente um problema na prática, essa teoria permanece uma " história mais ou menos ": uma hipótese muito convincente que nunca foi posta à prova e que não deve ser usado como argumento.

¹ Às vezes, esse problema é resolvido colocando tudo - inclusive o aparelho - na mesma linha:

if (condition)
{ do_something(); }

No entanto, acredito que é seguro dizer que a maioria das pessoas despreza isso. Além disso, ele teria os mesmos problemas que a variante sem chaves, por isso é o pior dos dois mundos.

Eu vou com o segundo. É mais sucinto e menos detalhado.

Eu tento não escrever para o menor denominador comum, então espero que outros desenvolvedores saibam como escrever uma das estruturas de fluxo de controle mais comuns na programação hoje.

Eu usaria o seguinte (o consenso aqui):

if (condition) {
    any_number_of_statements;
}

Também é possível:

if(condition) single_compact_statement;

Não é tão bom, especialmente em idiomas semelhantes ao C / C ++:

if(condition) 
    single_compact_statement;

(Nenhuma escolha aqui em Python ;-)

No Perl , você usaria:

$C = $A**3 if $A != $B;

ou

$C = $A**3 unless $A == $B;

(Este não é um pseudocódigo ;-)

Eu uso o método chaves - por todos os motivos acima, mais um.

O código é mesclado. Sabe-se que isso acontece em projetos nos quais trabalhei nessa declaração única, que foi quebrada por fusões automáticas. O mais assustador é que o recuo parece correto, mesmo que o código esteja errado, então esse tipo de bug é difícil de detectar.

Então eu vou com aparelho - em suas próprias linhas. É mais fácil identificar os níveis dessa maneira. Sim, desperdiça espaço na tela vertical e isso é uma desvantagem genuína. No entanto, acho que vale a pena.

Sem aparelho. Se algum outro programador adicionar uma segunda declaração ao meu código, não será mais minha culpa do que deixar alguém dirigir meu carro e eles atravessarem um penhasco.

Tivemos esse argumento mais de uma vez aqui, e o consenso geral é sempre usar aparelho. As principais razões são sobre legibilidade / manutenção.

Se você precisar adicionar código ao ifbloco, não precisará se lembrar / procurar chaves. Quando futuros programadores leem o código, as chaves são sempre inequívocas.

No lado positivo, o ReSharper adicionará automaticamente os aparelhos para programadores preguiçosos no Visual Studio, e presumo que haja complementos para outros IDEs que também o farão.

Eu uso a primeira sintaxe, quase sem exceção. Porque não pode ser mal interpretado .

"Não me faça pensar" não se aplica apenas a interfaces de usuário, todos ;-)

Eu pessoalmente prefiro o segundo. O primeiro parece feio, estranho e desperdiça espaço horizontal. Os principais problemas com o segundo são macros e as pessoas modificam seu código posteriormente, entendendo errado.

Para isso, eu digo "não use macros". Eu também digo: "indente seu maldito código corretamente". Considerando como todo editor de texto / IDE usado para programação faz recuo automaticamente, isso não deve ser tão difícil de fazer. Ao escrever código no Emacs, usaria o recuo automático para identificar se escrevi algo errado em uma linha anterior. Sempre que o Emacs começa a estragar o recuo, geralmente sei que fiz algo errado.

Na prática, acabo seguindo qualquer convenção de codificação que tenha sido definida diante de mim. Mas esses me incomodam (e me deixam muito mais feliz quando eu codigo em Python e todo esse desastre de suporte desaparece):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Então

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Embora honestamente, duas declarações em uma declaração if me incomodam muito mais do que uma única declaração. Principalmente porque os colchetes são obrigatórios e ainda parece engraçado com apenas duas instruções na instrução if.

Eu uso a versão de duas linhas sem chaves (o segundo formulário), mas não para economizar espaço.

Uso esse formulário porque acho mais legível, visualmente atraente e mais fácil de digitar. Eu só uso esse formulário se essas condições forem atendidas; ou seja, a ifcondição deve se encaixar perfeitamente em uma única linha e a instrução correspondente deve se encaixar perfeitamente na linha a seguir. Se não for esse o caso, usarei aparelhos para melhorar a legibilidade.

Se eu usar este formulário, verifique se há uma linha vazia (ou uma linha contendo apenas uma chave) antes e depois da ifdeclaração (ou acima do comentário, se houver). Embora essa não seja uma regra que eu sigo conscientemente, percebo isso agora depois de ler esta pergunta.

Economizar espaço na tela não é uma prioridade para mim. Se eu precisasse de mais espaço, usaria um monitor maior. Minha tela já é grande o suficiente para que eu possa ler qualquer coisa em que possa precisar focar minha atenção. É improvável que eu precise me concentrar em tantas linhas de código ao mesmo tempo que ocupem minha tela inteira. Se há tanto aninhamento acontecendo com um pedaço de código que eu não consigo entender sem visualizá-lo mais de uma vez, então eu teria que considerar se a lógica poderia ser melhor representada pela refatoração.

Abaixo estão alguns exemplos que demonstram como eu uso esse formulário da ifdeclaração.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Suspensórios. Sempre. Sou meio fã deles, porque isso dá ao código alguma consistência. E também como o @dsimcha escreveu - menos chance de erros ao adicionar linhas de código adicionais.

A "feiúra" de chaves em torno de uma única linha de código é menos prejudicial que o trabalho adicional, o que é provável nesses casos com depuração e / ou adição de código.

Pessoalmente, eu vou entre parênteses.

Por quê?

Bem, se alguém aparecer e precisar adicionar código à instrução if, é 100% claro onde está o escopo.

Ele mantém o formato das ifinstruções consistentes, independentemente de quantas instruções existem no bloco.

No entanto, se o estilo do projeto não for adequado, atenha-se a isso.

Eu quase sempre uso os suportes apenas para estar do lado seguro. No entanto, às vezes, se o conteúdo do bloco for realmente curto, eu os deixarei de fora e o tornarei único:

if (x==5) Console.WriteLine("It's a five!");

Prefiro chaves para consistência, mas não desperdiçando muito espaço em branco (o código formatado de forma mais legível está no meu campo de visão limitado). Então, eu escrevo isso para linhas curtas o suficiente:

If (cond) { statement; }

Eu costumo usar aparelho, mas há alguns casos em que não uso.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Para mim, seria tolo adicioná-los lá. Se alguém adicionar uma declaração após a ocorrência return, teremos problemas maiores do que problemas de escopo.

Se o IDE tiver formatação de código disponível, não uso chaves.

Por outro lado, onde o código pode ser editado em outros editores que não suportam a formatação automática, é perigoso não colocar chaves como mencionado em outras postagens. Mas mesmo assim eu prefiro não usar aparelho, e isso não foi problema para mim.