Estou olhando para o próximo Visual Studio 2017 .
Na seção intitulada Produtividade Aumentada, há uma imagem do Visual Studio sendo usada para substituir todas as ocorrências de var pelo tipo explícito.
Aparentemente, o código tem vários problemas que o Visual Studio identificou como 'precisa ser corrigido'.
Queria verificar novamente meu entendimento sobre o uso de var no C #, então li um artigo de 2011 de Eric Lippert chamado Usos e mau uso da digitação implícita .
Eric diz:
- Use var quando for necessário; quando você estiver usando tipos anônimos.
- Use var quando o tipo de declaração for óbvio no inicializador, especialmente se for uma criação de objeto. Isso elimina redundância.
- Considere usar var se o código enfatizar a “finalidade comercial” semântica da variável e diminuir os detalhes “mecânicos” de seu armazenamento.
- Use tipos explícitos se isso for necessário para que o código seja entendido e mantido corretamente.
- Use nomes descritivos de variáveis, independentemente de você usar “var”. Os nomes de variáveis devem representar a semântica da variável, não os detalhes de seu armazenamento; "DecimalRate" está incorreto; "InterestRate" é bom.
Eu acho que a maior parte do uso de var no código provavelmente está ok. Eu acho que seria bom não usar var para o bit que lê ...
var tweetReady = workouts [ ... ]
... porque talvez não seja 100% imediato de que tipo, mas mesmo assim eu sei rapidamente que é um boolean.
O uso de var para esta parte ...
var listOfTweets = new List<string>();
... parece-me exatamente como o bom uso de var, porque acho que é redundante fazer o seguinte:
List<string> listOfTweets = new List<string>();
Embora com base no que Eric diz, a variável provavelmente deve ser tweets em vez de listOfTweets .
Qual seria o motivo para alterar todo o varuso aqui? Há algo errado com esse código que estou perdendo?
fonte
varaqui são bons. Você poderia mudar uma - mas mesmo assim acho que não é realmente necessário. Por que alterá-los todos para o tipo explícito?varsforam marcados da mesma maneira; com a mesma marca cruzada de advertência ao lado deles e um sublinhado vermelho. Presumivelmente, o Visual Studio deseja corrigi-los da mesma maneira. A menos que eu esteja enganado.Respostas:
TL; DR: não, a Microsoft não está desencorajando o uso de 'var' em C #. A imagem está simplesmente sem contexto para explicar por que está reclamando.
Se você instalar o VS2017 RC e abrir o painel Opções e vá para
Text Editor -> C#, você verá uma nova seção:Code Style. Isso é semelhante ao que o ReSharper oferece há algum tempo: um conjunto de regras configuráveis para estilos de codificação.Ele inclui três opções para o uso de
var: para tipos incorporados , quando o tipo de variável é aparente e "Em outro lugar". Em cada caso, você pode especificar "preferir tipo explícito" ou "preferir var" e definir o nível de notificação como "nenhum", "sugestão", "aviso" ou "erro":fonte
var.var, então não me importo muito com o que os pontos de vista da MS têm sobre esse assunto.Eu acho que você está lendo demais. Portanto, há um recurso que permite substituir usos de digitação implícita por anotações explícitas de tipo, e você conclui que a digitação implícita é desencorajada. Também existe um recurso para compilar o código de bytes C♯ para CIL. Você conclui que o código C♯ é desencorajado e todos nós devemos escrever o código de código CIL? Provavelmente não.
A Microsoft está simplesmente mostrando o profundo entendimento que o IDE tem do seu código. Pode até escrever seus tipos para você sem precisar explicá-los. É isso aí.
Este é simplesmente um bom exemplo de exibição dos recursos de compreensão de código do IDE. É pequeno e independente (ao contrário de mostrar uma refatoração maior), está disponível em todas as edições e aplicável a todos os desenvolvedores (ao contrário de alguns dos recursos de visualização de arquitetura reconhecidamente muito impressionantes que estão disponíveis apenas no Ultimate e não são aplicáveis a uma parte significativa dos usuários em potencial do VS que nunca terão projetos tão grandes) e, embora seja muito simples (está literalmente fazendo exatamente o mesmo que
csc.exevem fazendo desde então)varfoi introduzido), certamente parece impressionante, especialmente para alguém que realmente não entende digitação implícita e inferência de tipo (ou que tenta pesquisar no Google "inferência de tipo" e fica sobrecarregado com termos como Hindley-Milner, unificação, retorno, quando na verdade A inferência somente local de C♯ é extremamente simples e direta).Então, resumindo: é uma maneira chamativa de exibir um recurso IDE.
fonte