Por remover usando directivas não utilizados em C #?

StackOverflow https://stackoverflow.com/questions/629667

  •  08-07-2019
  •  | 
  •  

Pergunta

Eu estou querendo saber se existem razões (para além de arrumar o código fonte) por que os desenvolvedores usar o recurso "Remover Usings não utilizado" no Visual Studio 2008?

Foi útil?

Solução

Existem algumas razões que você gostaria de tirá-los.

  • É inútil. Eles não acrescentam valor.
  • É confuso. O que está sendo usado de que namespace?
  • Se você não fizer isso, então você vai gradualmente se acumulam declarações using inúteis como seu código muda ao longo do tempo.
  • A análise estática é mais lento.
  • compilação do código é mais lento.

Por outro lado, não há muitas razões para deixar-los. Eu suponho que você salve-se o esforço de ter que excluí-los. Mas se você é aquele preguiçoso, você tem problemas maiores!

Outras dicas

Eu diria que muito pelo contrário -. É extremamente útil para remover desnecessários, declarações usando desnecessários

Imagine que você tem que voltar ao seu código em 3, 6, 9 meses - ou alguém tem de assumir o seu código e mantê-lo.

Se você tem uma enorme longa lista de lavanderia de usar declaração de que não são realmente necessários, olhando para o código poderia ser um pouco confuso. Por que é que o uso de lá, se nada for utilizado a partir desse namespace ??

Eu acho que em termos de manutenção de longo prazo em um ambiente profissional, eu sugiro fortemente para manter seu código o mais limpo possível - e isso inclui despejar coisas desnecessárias a partir dele. Menos desordem é igual a menos confusão e, portanto, maior capacidade de manutenção.

Marc

Isto parece-me ser uma questão muito sensível, que está sendo tratada de uma maneira muito leviana pelo povo que respondem.

Eu diria que qualquer mudança às necessidades de código fonte para ser justificada. Estas mudanças podem ter custos ocultos, ea pessoa colocar a questão queria estar cientes disso. Eles não pediu para ser chamado de "preguiçoso", como uma pessoa inimated.

Eu só comecei a usar ReSharper e ele está começando a dar avisos e dicas de estilo sobre o projeto eu sou responsável por. Entre eles é a remoção de redundante usando directiva, mas também qualificadores redundantes, capitalização e muitos mais. Meu instinto é para arrumar o código e resolver todas as dicas, mas minha cabeça negócio me adverte contra alterações injustificadas.

Nós usamos um processo de compilação automatizada e, portanto, qualquer mudança para o nosso repositório SVN geraria mudanças que nós não poderíamos link para projetos / bugs / problemas, e provocaria automatizado constrói e lançamentos que emitiram nenhuma alteração funcional para as versões anteriores.

Se olharmos para a remoção das eliminatórias redundantes, isso poderia causar confusão para os desenvolvedores como aulas de nossas camadas de Domínio e de dados só são diferenciados pelas eliminatórias.

Se eu olhar para o uso adequado de capitalização de anachronyms (ou seja ABCD -> Abcd). Então eu tenho que levar em conta que ReSharper não refatorar qualquer um dos arquivos XML que usamos que os nomes de classe de referência

Assim, seguindo estas sugestões não é tão simples e direta como parece, e deve ser tratado com respeito.

Menos opções no pop-up Intellisense (particularmente se os espaços de nomes contêm grande quantidade de métodos de extensão).

Teoricamente Intellisense deve ser mais rápido também.

Além das razões já expostas, evita conflitos de nomes desnecessários. Considere este arquivo: 

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

Este código não compila porque ambos os namespaces System.IO e System.Windows.Shapes cada um contém uma classe chamada Path. Nós poderíamos consertá-lo usando o caminho completo da classe, 

        private static string temporaryPath = System.IO.Path.GetTempFileName();

ou podemos simplesmente remover o using System.Windows.Shapes; linha.

removê-los. Menos código para olhar e admirar sobre economiza tempo e confusão. Gostaria que mais pessoas se manter as coisas simples, limpo e arrumado. É como ter camisas sujas e calças em seu quarto. É feio e você tem que perguntar por que ele está lá.

Ele também ajuda a evitar dependências circulares falsos, assumindo que você também é capaz de remover algumas referências dll / projeto de seu projeto após a remoção dos usings não utilizados.

Código compila mais rápido.

Pelo menos em teoria, se você fosse dado um arquivo C # cs (ou qualquer arquivo de código-fonte do programa single), você deve ser capaz de olhar para o código e criar um ambiente que simula tudo o que precisa. Com alguma técnica compilação / análise você pode até criar uma ferramenta para fazê-lo automaticamente. Se isso for feito por você, pelo menos na mente, você pode garantir que você entender tudo o que arquivo de código diz.

Agora considere, se você fosse dada uma ficheiro.cs com 1000 directivas using quais apenas 10 foram efectivamente utilizadas. Sempre que você olhar para um símbolo que é recém-introduzido no código que faz referência ao mundo exterior, você terá que passar por essas 1000 linhas para descobrir o que é. Esta é, obviamente, retarda o procedimento acima. Então, se você pode reduzi-los a 10, ele vai ajudar!

Na minha opinião, o C # using directiva é muito, muito fraco, uma vez que não é possível especificar símbolo genérico único sem genericidade sendo perdida, e você não pode usar using directiva alias para métodos de extensão uso. Este não é o caso em outras linguagens como Java, Python e Haskell, nessas línguas que são capazes de especificar (quase) exatamente o que você quer do mundo exterior. Mas evento, em seguida, vou sugerir a utilização using apelido sempre que possível.

Recentemente, recebi outra razão pela qual excluindo as importações não utilizadas é bastante útil e importante.

Imagine que você tem dois conjuntos, onde um referências a outra (por agora vamos chamar o primeiro A uma ea B referenciados). Agora, quando você tem o código em A que depende do B está tudo bem. No entanto, em algum momento em sua processo de desenvolvimento que você perceber que você realmente não precisa de que o código mais, mas você deixar o utilizando-declaração onde estava. Agora você não só tem um using-directiva sem sentido, mas também um montagem de referência para B que não é usado em qualquer lugar, mas na directiva obsoleta. Isso em primeiro lugar aumenta a quantidade de tempo necessário para compilar A, como B tem de ser carregado também.

Portanto, este não é apenas um problema em mais limpo e mais fácil de ler o código, mas também na manutenção de montagem referências na produção de código, onde nem todos os assemblies referenciados mesmo exist .

Finalmente em nossa exapmle tivemos que enviar B e A em conjunto, embora B não é usado em qualquer lugar A, mas na seção using. Isso vai afetar maciçamente a tempo de execução -Desempenho de A quando Carregando do conjunto.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top