O que você acha da dobragem de código?[fechado]

https://stackoverflow.com/questions/5916

08-06-2019
|

Pergunta

Para aqueles que estão no ambiente do Visual Studio, como você se sente ao agrupar qualquer código em #regions?(ou se algum outro IDE tiver algo semelhante...)

Solução

9 em cada 10 vezes, a dobragem de código significa que você não conseguiu usar o Princípio SoC pelo que vale a pena.
Sinto mais ou menos a mesma coisa em relação às aulas parciais.Se você tem um pedaço de código que você acha que é muito grande, você precisa dividi-lo em partes gerenciáveis (e reutilizáveis), e não ocultá-lo ou dividi-lo.
Ele vai te morder na próxima vez que alguém precisar alterá-lo e não conseguir ver a lógica escondida em um método monstro de 250 linhas.

Sempre que puder, extraia algum código da classe principal e coloque-o em uma classe auxiliar ou de fábrica.

foreach (var item in Items)
{
    //.. 100 lines of validation and data logic..
}

não é tão legível quanto

foreach (var item in Items)
{
    if (ValidatorClass.Validate(item))
        RepositoryClass.Update(item);
}

Meus $ 0,02 de qualquer maneira.

Outras dicas

Isso foi falado em Codificação de terror.

Minha convicção pessoal é que eles são úteis, mas como qualquer coisa em excesso pode ser demais.

Eu o uso para ordenar meus blocos de código em:
Enumerações
Declarações
Construtores
Métodos
Manipuladores de eventos
Propriedades

Às vezes, você pode acabar trabalhando em uma equipe onde #regions são incentivados ou exigidos.Se você é como eu e não aguenta mexer com código dobrado, você pode desativar o delineamento para C#:

Opções -> Editor de Texto -> C# -> Guia Avançado
Desmarque a opção "Entrar no modo de estrutura de tópicos quando os arquivos forem abertos"

Eu uso #Region para ocultar código feio e inútil gerado automaticamente, que realmente pertence à parte gerada automaticamente da classe parcial.Mas, ao trabalhar com projetos antigos ou atualizados, você nem sempre tem esse luxo.

Quanto a outros tipos de dobramento, eu dobro Funções o tempo todo.Se você nomear bem a função, nunca precisará olhar para dentro, a menos que esteja testando algo ou (re)escrevendo-o.

Embora eu entenda o problema que Jeff, et.al.tenho com as regiões, o que eu não entender é por que bater CTRL+M,CTRL+eu expandir todas as regiões em um arquivo é muito difícil de lidar.

eu uso Companheiro de texto (somente Mac) que possui dobramento de código e acho que é realmente útil para funções de dobramento, eu sei o que minha função "getGet" faz, não preciso que ela ocupe 10 linhas de um espaço tão valioso na tela.

Eu nunca o uso para ocultar um loop for, instrução if ou similar, a menos que mostre o código para outra pessoa, onde ocultarei o código que ela viu para evitar mostrar o mesmo código duas vezes.

Prefiro aulas parciais em vez de regiões.

O uso extensivo de regiões por outros também me dá a impressão de que alguém, em algum lugar, está violando o Princípio da Responsabilidade Única e tentando fazer muitas coisas com um único objeto.

@Tom

Classes parciais são fornecidas para que você possa separar o código gerado automaticamente pela ferramenta de quaisquer personalizações que você possa precisar fazer após a geração do código ter terminado.Isso significa que seu código permanece intacto depois que você executa novamente o codegen e não é substituído.Isto é uma coisa boa.

Não sou fã de aulas parciais - procuro desenvolver minhas aulas de forma que cada turma tenha um problema único e bem claro pelo qual é responsável.Para esse fim, não acredito que algo com uma responsabilidade clara deva ser dividido em vários arquivos.É por isso que não gosto de aulas parciais.

Dito isto, estou em dúvida sobre as regiões.Na maioria das vezes, eu não os uso;no entanto, eu trabalho com código todos os dias que inclui regiões - algumas pessoas são muito pesadas com eles (dobrando métodos privados em uma região e, em seguida, cada método dobrado em sua própria região), e algumas pessoas são leves sobre eles (dobrando enums, dobrar atributos, etc.).Minha regra geral, a partir de agora, é que eu só coloco código em regiões se (a) os dados provavelmente permanecerão estáticos ou não serão tocados com muita frequência (como enums), ou (b) se houver métodos que são implementados por necessidade devido à implementação de subclasses ou métodos abstratos, mas, novamente, não serão tocados com muita frequência.

Regiões nunca devem ser usadas dentro de métodos.Eles podem ser usados para agrupar métodos, mas isso deve ser tratado com extremo cuidado para que o leitor do código não enlouqueça.Não faz sentido dobrar métodos por seus modificadores.Mas às vezes dobrar pode aumentar a legibilidade.Por exemploagrupar alguns métodos que você usa para solucionar alguns problemas ao usar uma biblioteca externa e que você não deseja visitar com muita frequência pode ser útil.Mas o codificador deve sempre buscar soluções como agrupar a biblioteca com classes apropriadas neste exemplo específico.Quando tudo mais falhar, use a dobra para melhorar a legibilidade.

Esta é apenas uma daquelas discussões bobas que não levam a lugar nenhum.Se você gosta de regiões, use-as.Caso contrário, configure seu editor para desativá-los.Aí todo mundo fica feliz.

A dobragem de regiões seria adequada se eu não tivesse que manter manualmente os agrupamentos de regiões com base nos recursos do meu código que são intrínsecos à linguagem.Por exemplo, o compilador já sabe que é um construtor.O modelo de código do IDE já sabe que é um construtor.Mas se eu quiser ter uma visão do código onde os construtores estão agrupados, por alguma razão eu tenho que reafirmar o fato de que essas coisas são construtores, colocando-os fisicamente juntos e depois colocando um grupo em torno deles.O mesmo vale para qualquer outra maneira de dividir uma classe/estrutura/interface.E se eu mudar de ideia e quiser ver o material público/protegido/privado separado primeiro em grupos e depois agrupado por tipo de membro?

Usar regiões para marcar propriedades públicas (por exemplo) é tão ruim quanto inserir um comentário redundante que não acrescenta nada ao que já é discernível no próprio código.

De qualquer forma, para evitar ter que usar regiões para essa finalidade, escrevi um suplemento IDE gratuito e de código aberto do Visual Studio 2008 chamado Ora.Ele fornece uma visualização agrupada automaticamente, tornando muito menos necessário manter o agrupamento físico ou usar regiões. Você pode achar útil.

Geralmente acho que, ao lidar com códigos como Eventos em C#, onde há cerca de 10 linhas de código que são, na verdade, apenas parte de uma declaração de evento (a classe EventArgs, a declaração de delegado e a declaração de evento), colocar uma região ao redor deles e, em seguida, desdobrá-los do caminho torna-o um pouco mais legível.

Acho que é uma ferramenta útil, quando usada corretamente.Em muitos casos, sinto que métodos, enumerações e outras coisas que são frequentemente dobradas deveriam ser pequenas caixas pretas.A menos que você precise olhar para eles por algum motivo, seu conteúdo não importa e deve ser o mais oculto possível.No entanto, nunca desisto de métodos privados, comentários ou classes internas.Métodos e enums são realmente as únicas coisas que dobrei.

Minha abordagem é semelhante a algumas outras aqui, usando regiões para organizar blocos de código em construtores, propriedades, eventos, etc.

Há um excelente conjunto de macros VS.NET de Roland Weigelt disponível em seu blog, Melhor suporte de teclado para #region...#endregion.Eu uso isso há anos, mapeando ctrl+.para recolher a região atual e ctrl++ para expandi-la.Descubra que funciona muito melhor que a funcionalidade padrão do VS.NET que dobra/desdobra tudo.

Eu pessoalmente uso #Regions o tempo todo.Acho que isso me ajuda a manter coisas como propriedades, declarações, etc. separadas umas das outras.

Esta é provavelmente uma boa resposta também!

Codificação de terror

Editar:Droga, Pat me venceu nisso!

Eu prefiro #regions, mas um antigo colega de trabalho não suportava ter coisas escondidas.Eu entendi o que ele queria dizer quando trabalhei em uma página com 7 #regiões, pelo menos 3 das quais foram geradas automaticamente e tinham o mesmo nome, mas em geral acho que são uma maneira útil de dividir as coisas e manter tudo menos desordenado.

Eu realmente não tenho problemas em usar #region para organizar o código.Pessoalmente, normalmente configurarei regiões diferentes para coisas como propriedades, manipuladores de eventos e métodos públicos/privados.

O Eclipse faz parte disso em Java (ou PHP com plug-ins) por conta própria.Permite dobrar funções e tal.Eu costumo gostar disso.Se eu sei o que uma função faz e não estou trabalhando nela, não preciso olhar para ela.

O Emacs tem um modo menor dobrável, mas eu só o aciono ocasionalmente.Principalmente quando estou trabalhando em alguma monstruosidade herdada de outro físico que evidentemente tinha menos instrução ou se preocupava menos com suas práticas de codificação.

Usando regiões (ou código dobrável) deve não tenha nada a ver com cheiros de código (ou ocultá-los) ou qualquer outra ideia de ocultar código que você não deseja que as pessoas vejam "facilmente".

Regiões e dobramento de código têm como objetivo fornecer uma maneira de agrupar facilmente seções de código que podem ser recolhidas/dobradas/ocultadas para minimizar a quantidade de "ruído" estranho em torno do que você está trabalhando atualmente.Se você configurar as coisas corretamente (ou seja, nomear suas regiões com algo útil, como o nome do método contido), poderá recolher tudo, exceto a função que está editando no momento, e ainda manter algum nível de contexto sem precisar realmente ver o outro linhas de código.

Provavelmente deveria haver algumas diretrizes de melhores práticas em torno dessas ideias, mas eu uso regiões extensivamente para fornecer uma estrutura padrão para meus arquivos de código (agrupo eventos, campos de toda a classe, propriedades/métodos privados, propriedades/métodos públicos).Cada método ou propriedade também possui uma região, onde o nome da região é o nome do método/propriedade.Se eu tiver vários métodos sobrecarregados, o nome da região será a assinatura completa e todo o grupo será agrupado em uma região que é apenas o nome da função.

Eu pessoalmente odeio regiões.O único código que deveria estar nas regiões, na minha opinião, é o código gerado.Quando abro um arquivo sempre começo com Ctrl+M+O.Isso se dobra para o nível do método.Quando você tem regiões, você não vê nada além de nomes de regiões.

Antes de fazer check-in, agrupo métodos/campos logicamente para que fique ok após Ctrl+M+O.Se você precisar de regiões, terá muitas filas em sua turma.Também acho que isso é muito comum.

região ThisLooksLikeWellOrganizedCode BecauseIUseRegions

// lixo total, sem estrutura aqui

região final

Enumerações

Propriedades

.ctors

Métodos

Manipuladores de eventos

É só para isso que uso regiões.Eu não tinha ideia de que você poderia usá-los dentro de métodos.

Parece uma péssima ideia :)

O Codificação de terror Este artigo real também me fez pensar sobre isso.

Geralmente, em classes grandes, colocarei uma região em torno das variáveis, constantes e propriedades dos membros para reduzir a quantidade de texto que preciso percorrer e deixarei todo o resto fora de uma região.Nos formulários, geralmente agruparei as coisas em "variáveis, constantes e propriedades de membros", funções de formulário e manipuladores de eventos.Mais uma vez, isso é mais para que eu não precise percorrer muito texto quando quero apenas revisar alguns manipuladores de eventos.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow