Lidar com sopa de chaves

Programei em C # e VB.NET por anos, mas principalmente em VB. Estou mudando de carreira para C # e, no geral, gosto mais de C #.

Um problema que estou tendo, no entanto, é a sopa de chaves. No VB, cada palavra-chave de estrutura possui uma palavra-chave estreita correspondente, por exemplo:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

O mesmo código escrito em C # acaba sendo muito difícil de ler:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

Por estar tão acostumado com o VB, gostaria de saber se existe uma técnica empregada pelos programadores do estilo c para melhorar a legibilidade e garantir que seu código acabe no "bloco" correto. O exemplo acima é relativamente fácil de ler, mas às vezes no final de um código eu tenho 8 ou mais níveis de chaves, exigindo que eu role várias páginas para descobrir qual chave termina o bloco em que estou interessado dentro.

Coloque sua chave inicial na mesma "classificação" que a final, assim:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• Dependendo do seu IDE: coloque o cursor na chave de abrir / fechar e ela destacará isso e a chave correspondente.
• Recolha o bloco e ele mostra onde ele abre / fecha.
• Escreva blocos de código menores. Seriamente. Confira Clean Codee nunca mais encontre esse problema (e tenha um código mais legível / de manutenção).

Uma observação: o seguinte é uma sintaxe c # válida que pode ajudar sua situação específica:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

Uma convenção comum é adicionar um comentário após a chave de fechamento para indicar a estrutura que está sendo fechada:

if {
   ...
} // end if

while (condition) {
   ...
} // end while

etc. Eu nunca me esqueci dessa convenção, mas algumas pessoas acham útil.

Em geral, quando é difícil combinar chaves entre qualquer estilo - provavelmente significa que o método é muito longo e deve ser re-fatorado.

Eu acho que você precisa resistir com o aparelho. Eventualmente, eles se tornarão uma segunda natureza para você e você estará se perguntando como você viveu sem eles.

Porém, verifique se eles estão recuados adequadamente e se alguma convenção de espaçamento está sendo seguida (não importa qual).

Eu removo 2 níveis de aninhamento, recolhendo o espaço para nome e os escopos de classe horizontalmente. Observe que os métodos estão alinhados com a borda esquerda da tela. Não vejo sentido em perder 2 níveis de recuo em cada arquivo.

Depois disso, é raro que você tenha um aninhamento com mais de 4 níveis de profundidade.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Decidi recentemente tentar formalizar duas regras sobre construções de controle de fluxo que basicamente são assim:

• Você deve ter apenas construções de fluxo de código necessárias
• Você deve tornar as construções de fluxo de código tão pequenas quanto possível

Por exatamente os motivos que você mencionou e está claramente ciente, acho que essas são ótimas regras a serem seguidas. Existem algumas técnicas simples que você pode empregar para realizá-las:

• Saia do escopo assim que possível (isso inclui o escopo de loops e também de funções)
• Observe os elses que podem ser mitigados ao sair da função do if anterior e aplique a técnica de saída do escopo, como mencionei
• Inverta suas verificações condicionais quando o código dentro de um if for grande do que fora
• Fatorar o código dentro de um loop para outro método quando o tamanho do loop aumentar para obscurecer o restante do método
• Observe se há escopos que contenham apenas outro escopo, por exemplo, uma função cujo escopo inteiro seja preenchido por um if sem nada fora do if

Eu detalhei aqui exemplos de como não seguir esses procedimentos pode acabar fazendo o que você disse e colocando o código no bloco de código errado, o que é ruim e uma causa fácil de erros durante a manutenção.

Esta é uma das causas mais antigas de guerra na computação, infelizmente. Argumentos razoáveis ​​podem ser feitos de ambos os lados (melhor economia imobiliária vertical versus capacidade mais fácil de combinar visualmente a chave de abertura com a chave de fechamento), mas, na realidade, um simples formatador de código-fonte resolverá tudo para você. O MS Visual C # possui um que funciona bem.

Entretanto, esteja avisado de que se você estiver trabalhando como parte de uma equipe, deverá obedecer às convenções usadas por essa equipe; portanto, vale a pena ganhar alguma familiaridade com os dois estilos e abster-se de se tornar religioso.

Portanto, enquanto você estiver aprendendo, enfoque o estilo que facilita o aprendizado, mas fique de olho no outro enquanto estiver trabalhando e você se sairá bem.

Use o Resharper, que ajudará a recomendar maneiras de reduzir o aninhamento. Leia também o livro Clean Code , de Bob Martin , que enfatiza que uma função deve fazer apenas uma coisa e, portanto, cada função deve ter apenas meia dúzia de linhas, para que você não tenha tantos níveis de aninhamento com os quais se preocupar.

Há um complemento para o editor que pode ajudá-lo em: Estrutura de tópicos do C # .

O complemento estende o editor VS20xx para C # adicionando recursos para recolher, expandir e destacar blocos de código aninhados. Esses recursos permitem edição e leitura mais fáceis do conteúdo aninhado de blocos de código, como se, enquanto, etc.

Se você escrever seu código no Visual Studio, também haverá um plug-in que mostra pontos verticais entre o início e o final de cada estrutura que você constrói.

Mas, no geral, acho que levará algum tempo até que você esteja acostumado à "Sopa de chaves". (Aliás, eu realmente gosto dessa expressão. Parece um nome de episódio para The Big Bang Theory)

O recuo informa onde você está, nos dois estilos de sintaxe. Se você escrever um programa VB ou um programa C # em uma única linha, em breve não poderá saber onde está na sintaxe aninhada. A máquina analisa as frases finais do bloco ou chaves, mas os humanos precisam de indentação.

As frases de final de bloco vêm de uma era de cartões perfurados e fita de papel, quando a programação era muito menos interativa e visual. Ou, realmente, não é interativo. Era difícil entrar nos programas e, portanto, os programadores precisavam que os compiladores fossem muito inteligentes quanto à análise de sintaxe e recuperação de erros.

Naquela época passada, o ciclo de edição, compilação e execução poderia envolver a preparação de cartões perfurados com um perfurador de cartões e, em seguida, alinhando-se a uma janela de envio de trabalho em que um funcionário pegava os cartões perfurados e os submetia à máquina. Mais tarde, o programador coletaria a saída (impressa em papel) de outra janela. Se o programa apresentasse erros, a saída consistiria apenas no diagnóstico do compilador. Quando os tempos de resposta são longos, o custo adicional de digitação end ifem vez de apenas )se justifica se ele ajuda a melhorar a qualidade do diagnóstico, porque as necessidades programador para corrigir tantos erros quanto possível em uma única iteração para reduzir o número de perdas de tempo iterações através da janela de envio de tarefas.

Quando falta uma chave de fechamento, é difícil dizer qual chave é a que não está fechada. (O compilador pode ter que analisar o recuo para fazer uma estimativa.) Se você excluir uma chave de fechamento dentro de uma função, parece que o restante do arquivo faz parte dessa função, resultando em uma enxurrada de mensagens de erro inúteis. Considerando que, se você tiver uma end functionsintaxe, o compilador poderá deduzir onde a função incorreta termina, recuperar e analisar as funções subseqüentes corretamente, fornecendo diagnósticos adicionais, se houver, que sejam significativos.

Quando você trabalha no editor de texto com reconhecimento de código, que recua e colore automaticamente o código, em uma tela de alta resolução na qual é possível ver sessenta ou mais linhas, os argumentos para esses tipos de idiomas desajeitados não se aplicam mais. Você pode editar e reconstruir incrementalmente os programas tão rapidamente que pode lidar com um erro de cada vez. Além disso, vendo grandes seções do programa simultaneamente na tela e mantendo o recuo adequado, você pode reduzir a ocorrência desses tipos de erros de aninhamento em primeiro lugar. E um bom editor de texto de programação sinaliza alguns tipos de erros de sintaxe enquanto você digita. Além disso, existem editores dobráveis ​​que recolherão os blocos de um programa com base em sua sintaxe, fornecendo uma visão "estrutura de tópicos" de sua estrutura.

O Lisp usou parênteses desde o início e, talvez, não por acaso, os hackers do Lisp foram pioneiros na programação como uma experiência interativa, construindo sistemas que aceitavam programas em pequenos pedaços (expressões).

Na verdade, você não precisa de símbolos finais, como ilustra a linguagem Python. A identificação pode ser apenas a estrutura. Os seres humanos já usam recuo para grok a estrutura do código, mesmo em idiomas onde a máquina depende de símbolos ou frases finais.

Se você estiver usando um IDE, basta pressionar Crtl+ k+ De o IDE fará o resto do trabalho.