Re: [dotnetarchitects] A tipagem implícita e seus malefícios (ou benefícios)

[Márcio Fábio Althmann]

Eu acho que culpar o var não faz sentido, aqui tem mais detalhado o que eu penso a respeito http://www.marcioalthmann.net/2010/09/preconceito-com-a-keyword-var/

-- 

Márcio Fábio Althmann

Sent with Sparrow

On Friday, August 3, 2012 at 5:23 PM, Francisco Berrocal wrote:

Senhores, li um post do Shannon Whitley hoje:

http://www.voiceoftech.com/swhitley/index.php/2012/08/stop-using-var/

Realmente, cada vez mais vejo pessoas usando a expressão "var", que nada mais

é do que a tipagem implícita da variável declarada.

Na minha opinião, ainda é uma tipagem forte, porém não mais declarada, e só agrega benefícios na leitura do código.Mas Shannon Whitley diz que a expressão é para preguiçosos, e deveria ser evitada.(Acho ele até um pouco extremista e polêmico deste ponto de vista).

É importante citar também que plugins consolidados como o ReSharper trazem por default a declaração otimizada para o uso do var.(Configurável)

(http://stackoverflow.com/questions/1873873/why-does-resharper-want-to-use-var-for-everything)

E vocês o que acham deste modo de declaração? Afinal, o uso do "var" para declarar variáveis melhora a qualidade de entendimento do código?

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com

Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Giovani Barili]

Talvez seja uma pergunta boba, mas qual é a vantagem de utilizar "var" em vez da tipagem específica?

Isso pode gerar uma melhora em processamento, desempenho.. etc?

Obrigao,

[Juan Lopes]

Evitar redundância. Nenhuma diferença em runtime.

O ponto é que var - mais do que tipagem forte - é tipagem estática tanto quanto definir o tipo explicitamente. Você tem os mesmos benefícios de análise estática que tinha antes. A única diferença é que há inferência de tipos.

Eu sou um dos grandes defensores da tipagem estática. Mas não sou defensor da redundância para melhorar a legibilidade do código. Detesto erros de compilação que significam - na verdade - "ei, programador, você esqueceu de ser redundante aqui". Se o único argumento dos que são contra o "var" é que você não sabe exatamente qual o tipo da sua variável, acho que todo o ponto da análise estática se perde, no fim das contas.

E coitado do Haskell.

2012/8/5 Giovani Barili <giovanima...@gmail.com>

--
https://github.com/juanplopes

[Cezar Augusto Guimaraes Neto]

Eu particularmente sou a favor de user "var". Concordo que em algumas raras exceções deixar o tipo explicito pode ajudar no "readability". No meu time o que normalmente acontece e que o var é utilizado e quando estas raras exceções ocorrem usamos o tipo explicito.

Eu nunca tive problemas com variáveis que estavam declaradas com var em vez de ter o tipo explicito. E eu praticamente não uso o mouse enquanto estou desenvolvendo. 

Independente da minha opnião, achei que o post força um pouco a barra. Tanto que no exemplo ele coloca esta frase: "And what if this code is pulled into a blog post or used in a code walkthrough where Intellisense isn’t available?"

Criticar o uso do var porque você pode postar este código ou usá-lo em um "code walkthrough" é forçar muito a barra para mim.

[]s

Cezar.

cezarguimaraes.com

[Daniel Moreira Yokoyama]

Eu não vejo sentido nessa discussão.

Não usar var é mera ignorância ou pura burrice. É como você dizer pro balconista: eu quero um café do tipo café.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Winston Pacheco Junior]

Pior que é mesmo...

Eu não usaria var se as minhas variáveis se chamassem a, b, c (ou qualquer coisa que não faça sentido algum num contexto), de resto...

Não tem sentido deixar de usar algo menos "verboso" e que não prejudica em nada a performance por uma suposta legibilidade maluca...

[Francisco Berrocal]

Senhores, é importante notar a complexidade dos exemplos abordados ou simular ambientes tão próximos dos reais quanto possíveis.

No exemplo de Márcio F. Althmann temos algo como:

string nome = "João Silva"

var nome = "João Silva"

okay, isso realmente não interfere na leitura do código, e o uso do var se torna propício.

Agora quando em 5000 linhas de código encontramos algo como

var variable1 = something;

var variable2 = variable1;

Não sabemos ao certo o que realmente variable2 significa.

Então você pode citar a coerência no nome da variável.Okay, mas e se o nome da variável, fosse por exemplo: "CPFpessoa"

Faz sentido não faz?Mas o que é realmente "CPFpessoa" ? Pode ser string, atributo provito de um struct ou uma classe, decimal...

@dmyoko diz que não usar var é mera ignorância ou burrice, mas note a simplicidade da analogia abordado por ele denovo.

Podemos tomar como exemplo a aplicação de um BuiderPattern com a chamada de outro método no final.

Se tivésemos algo como:

var balance = new Balance().add(produto1).add(produto2).getBalance();

O que balance é? Um objeto? Um produto? Um int? Um float? Um double?

Afinal, o var não deveria ser usado apenas para tipos anônimos?

E realmente utilizar var em declarações de variáveis dos quais você já sabe, faz realmente sentido?

[Fernando Mondo]

Uma vez no GUJ (forum de Java) me disseram que era gambiarra o var (quando citei como uma das vantagens do c#), acho isso uma besteira, é a mesma vantagem da declaração Diamont do Java.

Eu uso o var sempre junto ao new, pois realmente ocorre redundância neste caso.

Já para retorno de métodos acho melhor dizer explicitamente o tipo recebido, fica mais fácil de ler.

--

[Luciano Castro]

E se passar o mouse em cima do var??? alguém lê código como se estivesse lendo um romance impresso em papel?? Acho que  sempre vai se ter a IDE VS para poder ler o código com o mouse em cima ele já mata todas as tuas dúvidas.

Concordo que o uso abusivo de VAR com nomes sem semântica deixa o código um pouco ruim de ler/entender. Mas isso é a minha visão, e isso é como língua cada um tem a sua.

att

Luciano Castro

2012/8/6 Fernando Mondo <fernand...@gmail.com>

--
uuuuuuuuuuuuuuuuu
      B
      B
      B
      B
      B
UUUUUUUUUUUUUUU

[Francisco Berrocal]

Nem sempre dispomos do Visual Studio, lembre-se, é uma ferramenta paga,

E mesmo se o dispomos, não podemos contar que toda manutenção corretiva ou evolutiva sobre códigos que nós escrevemos seja feita numa IDE (Visual Studio).

E mesmo se o fosse, não ficaria puto se na maioria das variáveis tivesse que colocar o mouse em cima para ver o tipo dele?

[Daniel Moreira Yokoyama]

Você realmente acha tão incrivelmente difícil descobrir o que o objeto é? Somos desenvolvedores .Net, temos uma IDE sem a qual 80% dos desenvolvedores não conseguem escrever uma linha sequer de código (sim... 80% dos desenvolvedores .Net não conseguiriam viver sem o visual studio) enquanto rubistas, scaladores sequer possuem IDE's e se viram muito bem com inferência de tipos e duck typing.

Quer saber o que o seu "balance" é e não  consegue por que tem um var na frente? coloca a porra do cursor do mouse em cima que o visual studio mostra pra você.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 6 de agosto de 2012 09:01, Francisco Berrocal <fran...@gmail.com> escreveu:

--

[Daniel Moreira Yokoyama]

Fernando, essa facilidade de ler que você cita é virtual... é um mau-costume de programador. O problema é, se num refactoring, você muda o retorno do método, vc passa a ser obrigado a mudar também o tipo da referência, só por que você não quis colocar o var.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Luciano, não existe uso abusivo do VAR. O que existe é: se o compilador é capaz de inferir, deixe a inferência acontecer. VAR se aplica na grande maioria dos casos. "Por favor, compilador, se vira e descobre o que eu tô recebendo aqui..."

Ou seja, só não use var, quando o compilador te xingar.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Francisco, parabéns por ser um dos pouquíssimos desenvolvedores .Net que abre mão do uso do visual studio. Não que eu concorde que ele seja caro (pra mim, caro é o tempo que leva fazer qualquer coisa fora dele) mas existe a idéia de que desenvolvedor .net é preguiçoso demais pra entender que não precisa da IDE, e vc não é um deles. Parabéns.

No entanto... inferência de tipos não é exclusividade do C#. Scala é muito apoiada nisso, e eles também não usam IDE's. Isto pra citar um exemplo, eu poderia falar de F#, Haskell, enfim...

Então, cara... reafirmo: discutir o uso de var é mera ignorância. Você está muito apegado a algo totalmente desimportante por causa de um mau-costume. Se você tem 5000 linhas de código e não sabe o que variable2 é... eu te digo que, com certeza, var é o menor dos seus problemas.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Francisco Berrocal]

Talvez seja verdade o que você disse, dependemos do visual studio para muitas coisas.

Mas veja bem, se você se enquadra nos 80%, não pode esperar que eu me enquadre também,

Quero dizer com isto que não me considero um desenvolvedor independende de qualquer que seja a ferramenta.

Já desenvolvi em ambiente Unix, utilizando o Mono.

Todo e qualquer código que você escreve reflete não somente à você, mas para quaisquer programadores que 

darão suporte ao seu legado.

P.S.:Por favor, reveja seu linguajar.

Obrigado,

Att,

Francisco Hisashi Berrocal

[Daniel Moreira Yokoyama]

Não cara... não me enquadro nos 80%... mas isso não faz a menor diferença no tema que estamos discutindo. Se você já programou para UNIX utilizando MONO, troféu joinha, mas tu ainda não entendeu que o ponto que eu estou querendo chegar é que tipos estão lá... você não precisa vê-los pra saber que estão, e seu apêgo por eles está te atrapalhando a compreender o benefício da inferência de tipos. 

E também não estou disposto a rever meu linguajar. Eu gosto de me expressar exatamente como espero que me entendam. Se eu rever meu linguajar é capaz de você achar que não sou tão firme na idéia de que não usar var é burrice. (PS: se eu não tenho crédito, pelo menos dê crédito ao Resharper...)

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Felipe Aron]

kkkk -- Daniel moreira adorei a tua abordagem: 

"É como você dizer pro balconista: eu quero um café do tipo café."

--

Analista-Programador

#FollowMe: @felipearon (http://felipearon.net)

[Daniel Moreira Yokoyama]

Em 6 de agosto de 2012 09:46, Daniel Moreira Yokoyama <moreira....@gmail.com> escreveu:

(PS: se eu não tenho crédito, pelo menos dê crédito ao Resharper...)

Ou não.

[Francisco Berrocal]

@dmyoko, entendo que queira enfatizar sua ideia, mas há outras maneiras de faze-la, por favor evitemos palavras de baixo calão, nem todos se sentem a vontade.

Não entendi o "dê créditos ao ReSharper", você poderia explicar melhor, por favor?

[Daniel Moreira Yokoyama]

Exatamente este o ponto, Felipe.

Todo mundo sabe o que pede, mas de repente, não custa nada deixar claro. Afinal, quem garante que o café que ele vai me devolver seja realmente do tipo Café ***numa linguagem estaticamente tipada*** (mesmo que não fôsse...).

Trabalhei em um projeto onde me deparei com a seguinte situação... o cara fez um método GetClientes() (exemplo hipotético). E lá fui eu... colocar um IEnumerable<Cliente> pra receber... só que não era. Era um DataSet.

Pergunta... o problema era o meu IEnumerable ou era o DataSet???

E se fosse var??? faz alguma diferença?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

O Resharper te alerta para a redundância da tipagem no seu código, te orientando a usar var sempre que você não o fizer.

Mas como eu disse depois (atendendo ao seu pedido de rever meu linguajar): Não significa que você deva concordar com ele também.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 6 de agosto de 2012 09:51, Francisco Berrocal <fran...@gmail.com> escreveu:

@dmyoko, entendo que queira enfatizar sua ideia, mas há outras maneiras de faze-la, por favor evitemos palavras de baixo calão, nem todos se sentem a vontade.

Não entendi o "dê créditos ao ReSharper", você poderia explicar melhor, por favor?

--

[Winston Pacheco Junior]

Você tava fazendo uma piada né Francisco?

"var balance = new Balance().add(produto1).add(produto2).getBalance();

O que balance é? Um objeto? Um produto? Um int? Um float? Um double?"

CLARO que desse jeito ninguém vai saber o que é Balance, uma linha de código sem um contexto não faz sentido pra mim de maneira alguma. Se fosse:

Product balance = new Balance().add(produto1).add(produto2).getBalance();

ou

Balance balance = new Balance().add(produto1).add(produto2).getBalance();

ou

int balance = new Balance().add(produto1).add(produto2).getBalance();

ou

double balance = new Balance().add(produto1).add(produto2).getBalance();

Teria realmente mudado TODO o sentido pra você? Porque pra mim continuaria não fazendo sentido algum.

Sei lá, acho que talvez você consiga provar seu ponto com um exemplo bem melhor que esse (mas acho que você não vai encontrar um) porque, simplesmente, não faz muito sentido. A não ser que você tenha o costume de declarar variáveis no começo do seu código e ir instanciando elas durante o processo, o que é desnecessário atualmente, mas vá lá, gosto é gosto.

Em 6 de agosto de 2012 09:01, Francisco Berrocal <fran...@gmail.com> escreveu:

--

[Thiago Silva]

@Luciano:  "Concordo que o uso abusivo de VAR com nomes sem semântica deixa o código um pouco ruim de ler/entender "

O problema aí não é o VAR, é o nome sem semântica!!

2012/8/6 Winston Pacheco Junior <winston...@gmail.com>

[Giovani Barili]

Se o var não vai dar nenhum retorno de processamento, memória, facilidade de programação e etc... somente diminuir com a "redundância", vejo isso mais como uma forma de desenvolvimento até pessoal... 

Subjetividade pura.... já que não vai dar nenhum retorno

Com isso, qual o objetivo dessa discussão?

A única coisa que eu vejo é que para quem quer utilizar VAR blz, mas use uma boa semântica na declaração das variáveis para que o seu colega não se perder.

Como nosso coleta Thiago falou.

E em um cenário .NET, menos para ambientes UNIX, o VS indica o tipo de objetos sem problemas. Qual é o problema de usar ou não var?

Giovani Manica Barili

Mestre Eng. da Computação

Mobiltec - Mobilidate em Negócios

Contatos:
GoogleTalk: giovanimanicabarili

Skype: giovanibarilimobiltec

Celular: (54) 81328860

[Daniel Moreira Yokoyama]

O problema não está em usar... o problema está em não usar.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Denis Bittencourt Muniz]

Casos e casos. Em alguns casos sim, diminui a legibilidade do código, mas ser extremista e falar "gambiarra, NÃO USE!, etc", já é um exagero.

Para tipos de dados, cujo nome é muito grande, uso o var. Em geral, prefiro referir com o tipo de dado, por mero costume.

Onde uso bastante o "var": em construções de visões no MVC. Por mero costume, por acreditar não diminuir legibilidade do código, onde os nomes das variáveis, geralmente, claros para o contexto (a visão).

Já em expressão de regra de negócio, desenvolvimento de lógica de negócio, gosto de usar a tipagem.

[Daniel Moreira Yokoyama]

Cara... DRY: Don't repeat your self.

Quando não usar var? Quando o compilador (que é bem inteligente mesmo sendo o mais burro na cadeia entre o programador e o programa) não conseguir fazer a inferência (e que seja por alguma razão plausível, já que às vezes, até isso dá pra resolver).

Por exemplo, o compilador é incapaz de inferir isto:

var cliente;

Se você não inicializa, ele não sabe inferir o que virá da inicialização. (E olha que até você, programador, que diz ter problemas de legibilidade, sabe inferir o tipo neste caso).

var cliente = new Cliente(); (ajudou o compilador, e a si mesmo).

Não existem malefícios (esse papo de que perde legibilidade é algo que tá sendo dito sem parar um pouco pra pensar). Volto a dizer: rubistas não possuem IDE, e a tipagem deles é totalmente dinâmica. Saber se o valor é string ou int nunca foi um problema pra eles - e com o duck typing, chega até ser vantajoso. Não só os rubistas com tipagem dinamica, mas também as linguagens funcionais, onde toda a tipagem é feita através de inferência... Scala, Javascript...

Não existe problema de legibilidade. Existe problema de (mal-)costume. Para os que tem mal-costume, o resharper ajuda (ele te xinga se você não usar var).

É redundância desnecessária. É retroceder duas versões do C# (quase 3). É ignorar o que ficou pra trás. (de certa forma, muita gente nunca saiu do c# 2.0... pra não contar os que nunca chegaram nele - e não usam generics até hoje).

Todos os problemas relatados até aqui, não são problemas com o var... não diz respeito à inferência de tipos. Diz respeito, como sempre, a problemas de modelagem. Os casos citados: 5mil linhas de código, nomes grotescos, são problemas de modelagem e/ou design.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

--

[Winston Pacheco Junior]

E com inicializar pode ser uma inicialização nula também...

var teste = (string)null;
var teste2 = (Teste)null;

Se você estiver afim apenas de declarar, sei lá, por algum motivo que me foge a razão agora...

[Daniel Moreira Yokoyama]

Bem lembrado, Winston... embora, também não veja razão pra isto.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Juan Lopes]

Por mim, quanto mais inferências as linguagens estáticas forem capazes de fazer, melhor. O grande problema da grande maioria das linguagens estáticas hoje em dia é sua excessiva verbosidade, que as tornam completamente não amigáveis para iniciantes e tampouco introduzem uma semântica mais clara para os experientes.

Linguagens dinâmicas, por outro lado, são mais inseguras de uma forma geral, além de terem o overhead da resolução dinâmica de tipos.

O melhor seriam linguagens que evitassem toda essa verbosidade através de inferências, mas mantendo a segurança da análise estática. Temos diversos exemplos de linguagens assim. Em .NET temos dois ótimos representantes desse paradigma: Nemerle, que é bastante parecida com C#, mas cortando todo o bulshit; e Boo, que parece muito com python, mas que é tão estática quando C# (apesar de permitir duck typing através de construções especiais).

2012/8/6 Daniel Moreira Yokoyama <moreira....@gmail.com>

--
https://github.com/juanplopes

[Daniel Moreira Yokoyama]

Não posso deixar de falar (pela enésima vez) de scala. Que pra mim, neste quesito é a melhor... e que está carente de comunidade.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Eu uso tipagem explicita quando sei que o meu valor é daquele tipo e não muda dinamicamente, me sinto melhor fazendo assim.

Uso var quando não tenho certeza do retorno, principalmente utilizando expressoes lambda que retornam aqueles tipos chatos de fazer cast. 

Quando o recurso do var entrou no C# eu gostei muito! 

Só acho sacanagem usar var por preguica de "tipar" as variáveis. Podemos ter o minimo de coerencia na utilização.

Simples assim.

Enviado pelo meu iPhone.

[Giovani Barili]

+1

[Daniel Moreira Yokoyama]

Cara... vc não entendeu. Isso não é preguiça. Isto é eliminar redundância.

Apelo de novo pro exemplo que eu dei de alguém pedir um café do tipo café.

Inferência não é um recurso de preguiçoso. Inferência é uma forma de eliminar redundância, principalmente com os valores "que não mudam" como você diz.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 6 de agosto de 2012 17:10, Eduardo Pires <hea...@gmail.com> escreveu:

[Daniel Moreira Yokoyama]

Não é por nada não... eu começo a entender o motivo que todos os programadores que eu conheço de outras plataformas / linguagens torcem o nariz quando eu digo que trabalho com .Net.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Daniel, voce pode até discordar de mim, mas nao venha dizer que eu nao entendi!  

Eu entendo o conceito e dei minha opiniao prefiro usar tipagem explicita por que leio mais facil o codigo me sinto preguicoso sabendo que um NomeUsuario é String e o declaro como var

Va ate uma Starbucks e peça cafe! Vao te perguntar, quais dos 300 tipos???

Se vc declara tudo como var seja feliz! 

Como o topico da discussao eh se afeta em algo ou nao já ficou claro que nao tem diferença.

Enviado pelo meu iPhone.

[Juan Lopes]

Só para alinhar: "var" não diz que o tipo de uma variável pode mudar. Tampouco que ele é dinâmico. A resolução desse tipo é feita em tempo de compilação, tal qual seria se você declarasse o tipo explicitamente.

É bem diferente de usar "dynamic" pra todo o lado, por exemplo. "dynamic" tem impacto tanto em performance quanto na capacidade do compilador realizar otimizações em tempo de compilação. "var" não.

Usar "dynamic" indiscriminadamente, sim, é recurso de preguiçoso.

[Daniel Moreira Yokoyama]

Pode ter certeza que qualquer um dos 300 tipos de café não vai ser uma escova.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Winston Pacheco Junior]

+1

[Daniel Moreira Yokoyama]

Eu custo a entender o benefício de não usar var.

Eu acho inadmissível usar tipagem explícita. Neste ponto, bato palmas pro resharper, que sublinha a linha e avisa "Você está sendo redundante!". Preguiçoso é o cara que desabilita este tipo de aviso pra não ter que ignorá-lo toda vez que ele aparece.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Renato Cantarino]

Não vejo problema em usar o var.

qual a diferença "por baixo dos panos" para isso: int numero = 1;  var numero = 1;  ?

Att,

Renato Cantarino

[dm.ga...@gmail.com]

Na starbucks eu falo:

var cafe = Cafeteria.GetCafe("Espresso"); 

O compilador infere que eu quero um Café e sou feliz.  

Porém pode ocorrer que o tipo concreto seja um CafeEspresso mas meu GetCafe seja mais genérico 

ai eu falaria:

CafeEspresso cafe = Cafeteria.GetCafe("Espresso"); 

Que eu acho meu nojento. Tentaria ainda construir algo diferente como 

var cafe = Cafeteria.Get<CafeEspresso>(); 

Ou seja, dois pontos para o var!

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/6 Eduardo Pires <hea...@gmail.com>

[Daniel Moreira Yokoyama]

Nenhuma Cantarino. Nenhuma mesmo. Nem mesmo de legibilidade.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Que tipo de escova? De dentes? Para escovar cavalo, tapete?

Enviado pelo meu iPhone.

[Daniel Moreira Yokoyama]

Boa Deivison. 

Você ajuda o compilador, e ele continua te ajudando. Uma mão, lava a outra.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Tanto faz... vc pediu café... o tipo de escova que ele não vai retornar faz alguma diferença se o retorno é café?

Ou tem algum tipo de café que seja escova?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[dm.ga...@gmail.com]

É puro Syntactic Sugar  http://en.wikipedia.org/wiki/Syntactic_sugar 

O compilador no final das contas faz  "int numero = 1" para ambos os casos.

A responsabilidade de deixar seu código expressivo está mais no nome das funções, classes, etc; do que no coitado do var

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/6 Eduardo Pires <hea...@gmail.com>

Que tipo de escova? De dentes? Para escovar cavalo, tapete?

Enviado pelo meu iPhone.

[Renato Cantarino]

Boa Gandini.

Eu devo me preocupar com outras coisas e não com o uso do var.

As pessoas estão se tornando refém de "boas praticas" lido em qualquer site, feito por qualquer desenvolvedor.

Att,

Renato Cantarino

[Luciano Castro]

@Daniel cuidado.. o caminho da verdade absoluta é sempre muito perigoso.. 

Acho que esta thread já comprovou que há várias opiniões sobre usar ou não usar o recurso, mas é sempre no final uma questão de escolha, não existe o certo ou o errado, acho que se deve fazer o que for preciso para no fim tudo FUNCIONAR da forma que PRECISA para  QUEM VAI USAR, e não devemos nos apegar a detalhes tão pequenos.

Próximo assunto???

uuuuuuuuuuuuuuuuu
      B
      B
      B
      B
      B
UUUUUUUUUUUUUUU

[Gustavo Cruz]

+1 pro uso do var.

Se não tá legível, na minha opinião, é porque já ta na hora de rever a construção do codigo. E se chegou nesse ponto, considero ilegível usando ou não o var.

E na boa, não vem com essa de iniciante tem dificuldade pra ler e blah blah....se fosse assim não teríamos iniciantes em Phyton e tantas outras linguagens que usam inferência....

[dm.ga...@gmail.com]

E a para quem vai dar manutenção

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/6 Luciano Castro <luciano...@gmail.com>

[Daniel Moreira Yokoyama]

Amigo, a idéia de que não existe verdade absoluta é um bom argumento para várias discussões onde realmente não exista. Nesta discussão específica, existe.

Colocar o tipo explicitamente é basicamente dizer "eu sei que eu tô fazendo merda, mas eu quero garantir estou no controle desse código."

Ou talvez pq nunca compreendeu o uso do var, o que também não é difícil, como sabemos que tem programadores c# que nunca saiu do 2.0.

Para algumas discussões, uma cadeira é uma cadeira independente da opinião de quem queira dizer que o método pode retornar um cabo de vassoura correndo o risco de sentar no lugar errado.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Renato Cantarino]

kkkkkkk....

Att,

Renato Cantarino

[Marcus Alexandre Silva]

Nenhuma.
Mas se fosse short numero = 1 e var numero = 1 ai você teria problemas.
Uso e abuso dos var`s. Mas serio, ja cansei de argumentar com quem se
recusa a perceber seu valor. Parece que é algo que você tenta explicar
e as pessoas simplesmente não querem entender. Talvez por birra.

Em 6 de agosto de 2012 17:35, Renato Cantarino
<renato.c...@gmail.com> escreveu:

[Juan Lopes]

Por que essa discussão está tão pessoal?

2012/8/6 Renato Cantarino <renato.c...@gmail.com>

--
https://github.com/juanplopes

[Daniel Moreira Yokoyama]

Você acha?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Por que ao dar uma opinião pessoal qualquer um está prestes a ler que pessoas dessa opinião são isso fazem aquilo, escrevem código de merda e etcs...

Dentro do nível intelectual dos participantes dessa lista acho até estranho esse tipo de comportamento.

Até contribui um pouco com a gozação, penso que ninguém deveria se importar com julgamentos taxativos de quem nem vos conhece, stay cool :)

Enviado pelo meu iPhone.

[Antonio Pedro]

Prezados amiguinhos,

Não deixemos que esta thread que estava tão enriquecedora vire um barraco.

Voltemos a comparar o C# com o Haskell e outras linguagens de programação.

Att,

Antônio Nascimento

[Daniel Freire]

Foi quase um "queridos coleguinhas", rs

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
> Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--

Daniel C. Freire
(31) 8467-2331
@danielfreire

[Daniel Moreira Yokoyama]

Concordo, Juan... a discussão realmente virou muito pessoal.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Francisco Berrocal]

Senhores,
atritos à parte, agradeço a todos que participaram e participam da discussão.
Pois apesar da questão ser um pouco polêmica, devemos nos manter ativos na comunidade,
Vejo muitas perguntas do tipo "Para que esta discussão?", ou então "É apenas var, não há importância..."
Essas questões sim deviam ser banidas da mente das pessoas.

Devemos e somos responsáveis por evangelizar a cultura .NET, e suas boas práticas respectivamente.
Por menor que sejam as questões, SEMPRE há importância, essa questão é subjetiva, pois não há verdade absoluta(discordando de @dmyoko).

Por verdade absoluta, entendo uma verdade dogmática, isto é, uma unicidade na resposta, sendo assim não aceita outra solução.
Já a declaração de variáveis possui muitas formas de declarar, como já sabemos.

Não sou contra o uso do var, muito pelo contrário, eu estava apenas contra-argumentando.
Pretendo adotar um padrão, e para isso quis saber a opinião da comunidade.

Att,
Francisco Hisashi Berrocal

[João Bateloche]

O exemplo do short foi o único onde realmente me pareceu útil explicitar a tipagem.

No entanto, muito raramente isso fará alguma diferença prática, a economia de memória é mínima e na maior parte das vezes você não consegue garantir que o short seja sempre seguro para cobrir o range da variável.

E de fato, não deixar o compilador inferir o tipo da variável parece uma pouco pedir café do tipo café.

Mesmo quando o retorno do método é uma abstração para algo mais concreto você precisaria fazer o cast do objeto, o que faz com que o compilador consiga inferir perfeitamente a tipagem (acho que alguém citou isso como justificativa para explicitar a tipagem).

E abstrações devem ser aplicadas a mensagens, não a variáveis locais, esta são apenas alocações auxiliares.

[Daniel Moreira Yokoyama]

Eu não acho que existam verdades absolutas pra tudo. O famoso depende faz parte do meu questionário na maior parte das vezes.

É nesta discussão que eu acho que o depende não se enquadra. A parte mais engraçada é o fato de que isto não é "a minha opinião". Não tem "minha opinião" neste contexto.

Me falta, talvez, humildade pra simplificar isto, entende? Eu estou sendo totalmente incapaz de expressar o real sentido da questão. E eu nem quero apelar pra uma modéstia que eu não tenho e que não me compete fingir ter pra mudar o discurso: o uso de var é fundamentalmente correto, tornando somente a necessidade de tornar explícita a tipagem quando o compilador é incapaz de resolvê-lo, e ainda assim existem, na maioria das vezes, formas de ajudá-lo a resolver.

O grande problema, penso eu, é que, infelizmente, o var só surgiu na versão 3.0 do c#. Do contrário, esse tipo de discussão jamais existiria (e é aí que eu insisto: a discussão é, de fato, inútil).

Ou seja, desde a 1.0 o programador tá acostumado a fazer tipo x = new tipo(). E pra ele isto é tão natural que ele nem se questiona. Pelo contrário, o que mais houve foi o questionamento do surgimento do var. Foi o que eu mais ouvi na época: nossa, que gambiarra, olha o que a microsoft fez, tá transformando o c# no vb6... enfim, tudo o que foge do que ele está acostumado a fazer vira questionável. 

É a velha questão da mulher que corta o rabo do peixe pq foi assim que aprendeu com a mãe, que aprendeu com a vó, que aprendeu com a bisa... que só cortava o rabo do peixe pq a panela era pequena demais.

A panela agora aumentou, e não é mais necessário cortar o rabo do peixe, não por que o dmyoko acha isto, do contrário vc poderia chamá-lo de arrogante (como eu bem sei que sou e estou pouco ligando para o que pensam disto... é um problema que eu preciso tratar comigo antes de tratar com os demais).

Scala nasceu com inferência, por isto ninguém discute inferência lá. É o melhor exemplo que eu posso citar por que é a linguagem mais parecida com o C# que eu já curti desde a primeira vez que vi.

Mas C# aceita inferência, e o fato dele aceitar é a mesma questão de não precisar mais declarar fields para properties a menos que haja um bom motivo para fazê-lo, que é a mesma questão de consumir um método genérico sem precisar especificar o tipo por que ele infere no argumento, que é a mesma questão de não precisar cortar o rabo do peixe por que as panelas modernas são maiores.

Não é a minha opinião de merda... é a linguagem que você usa te oferencendo (aos berros) isto há quase 5 anos, dizendo: Não precisa disto. Não faça isto. Não use isto. Eu resolvo isto pra você.

O dmyoko é só o cara chato que tá tentando explicar que isto é tão verdadeiro quanto é ao dizer que eu sou chato. Talvez se eu for mais simpático alguém entenda melhor. Mas eu também não estou tão interessado assim em ser compreendido. Gosto de ver o circo pegando fogo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 6 de agosto de 2012 21:36, Francisco Berrocal <fran...@gmail.com> escreveu:

[Eduardo Pires]

Gostaria de saber a opinião de quem não usa tipagem explicita:

Quando vão escrever uma classe Model como vocês fazem?

class Cliente

{

       public string Nome { get; set; }

}

O uso do var é local apenas, uma hora tem que tipar ou estou falando besteira?

2012/8/6 João Bateloche <jbate...@gmail.com>

[Daniel Moreira Yokoyama]

Claro, o compilador não é capaz de inferir o tipo de uma property. Bem como parâmetros de um método ou construtor.

Ainda não chegamos no nível do F#... mas talvez, um dia, cheguemos. E quando chegarmos, até nestes pontos será melhor inferir.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[João Bateloche]

Acho que essa discussão deixou de ter sentido há algum tempo, o único ponto que fazia sentido discutir era a legibilidade do código, e nisto houve consenso que o sentido tem que estar no nome, e não no tipo.

Mas uma coisa é fato e extremamente irritante... Apesar de falarmos de uma área que envolve basicamente lógica e raciocínio analítico, é incrível como os desenvolvedores em geral são resistentes a mudança e tendem a se apegar quase que emocionalmente a algumas idéias e conceitos.

Não só a inclusão de alguma feature na linguagem, mas qualquer conceito novo, qualquer ferramenta nova que mude o que existe atualmente sofre resistência da comunidade geral. 

[Daniel Moreira Yokoyama]

+1

[Marcio Hiroyuki Miyamoto]

Às vezes eu me pergunto: Por que eu não participo mais das discussões do grupo?" Ai leio o que o Daniel diz e penso: "O Daniel já faz um excelente trabalho!" hahaha

Se legibilidade fosse problema, ninguém usava javascript, python, ruby... E convenhamos, ler código python é mole mole!

On 06/08/2012, at 16:31, Daniel Moreira Yokoyama <moreira....@gmail.com> wrote:

Cara... DRY: Don't repeat your self.

Quando não usar var? Quando o compilador (que é bem inteligente mesmo sendo o mais burro na cadeia entre o programador e o programa) não conseguir fazer a inferência (e que seja por alguma razão plausível, já que às vezes, até isso dá pra resolver).

Por exemplo, o compilador é incapaz de inferir isto:

var cliente;

Se você não inicializa, ele não sabe inferir o que virá da inicialização. (E olha que até você, programador, que diz ter problemas de legibilidade, sabe inferir o tipo neste caso).

var cliente = new Cliente(); (ajudou o compilador, e a si mesmo).

Não existem malefícios (esse papo de que perde legibilidade é algo que tá sendo dito sem parar um pouco pra pensar). Volto a dizer: rubistas não possuem IDE, e a tipagem deles é totalmente dinâmica. Saber se o valor é string ou int nunca foi um problema pra eles - e com o duck typing, chega até ser vantajoso. Não só os rubistas com tipagem dinamica, mas também as linguagens funcionais, onde toda a tipagem é feita através de inferência... Scala, Javascript...

Não existe problema de legibilidade. Existe problema de (mal-)costume. Para os que tem mal-costume, o resharper ajuda (ele te xinga se você não usar var).

É redundância desnecessária. É retroceder duas versões do C# (quase 3). É ignorar o que ficou pra trás. (de certa forma, muita gente nunca saiu do c# 2.0... pra não contar os que nunca chegaram nele - e não usam generics até hoje).

Todos os problemas relatados até aqui, não são problemas com o var... não diz respeito à inferência de tipos. Diz respeito, como sempre, a problemas de modelagem. Os casos citados: 5mil linhas de código, nomes grotescos, são problemas de modelagem e/ou design.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 6 de agosto de 2012 16:17, Denis Bittencourt Muniz <deni...@gmail.com> escreveu:

Casos e casos. Em alguns casos sim, diminui a legibilidade do código, mas ser extremista e falar "gambiarra, NÃO USE!, etc", já é um exagero.

Para tipos de dados, cujo nome é muito grande, uso o var. Em geral, prefiro referir com o tipo de dado, por mero costume.

Onde uso bastante o "var": em construções de visões no MVC. Por mero costume, por acreditar não diminuir legibilidade do código, onde os nomes das variáveis, geralmente, claros para o contexto (a visão).

Já em expressão de regra de negócio, desenvolvimento de lógica de negócio, gosto de usar a tipagem.

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Thiago Silva]

Concordo com o Márcio sobre o Daniel.

Existe algum argumento a favor de não usar o VAR que não seja o "porque gosto"?

2012/8/7 Marcio Hiroyuki Miyamoto <marcioh...@gmail.com>

[Antonio Pedro]

Isso é inerente do ser humano. Ninguém gosta de sair da zona de conforto.

O problema é que quando você está na zona de conforto, você parou de evoluir como pessoa.

Att,

Antonio Nascimento

---

Date: Mon, 6 Aug 2012 23:17:53 -0300
Subject: Re: [dotnetarchitects] Re: A tipagem implícita e seus malefícios (ou benefícios)
From: jbate...@gmail.com
To: dotnetar...@googlegroups.com

[dm.ga...@gmail.com]

Quando vcs tem um retorno de select vcs criam uma classe ou usam o tipo anonimo?

var carros = ObterCarros().Select( s => new(){ Placa =  s.Placa});

ou 

class Carro { public string Placa {get;set;}  }

var carros = ObterCarros().Select( s => new Carro(){ Placa =  s.Placa});

Claro que isso é exemplo que poderia crescer com uma composição de objeto. 

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/7 Antonio Pedro <apl...@hotmail.com>

[Renato Cantarino]

Prefiro as classes.

Att,

Renato Cantarino

[dm.ga...@gmail.com]

Mas vc não acaba escrevendo muito para fazer operações pequenas?

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/7 Renato Cantarino <renato.c...@gmail.com>

[Daniel Moreira Yokoyama]

Eu, particularmente, não crio classes só para o retorno de selects, mas é muito difícil precisar retornar anônimos... situações muito, mas muito específicas mesmo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Renato Cantarino]

Sim, classes.

A galera não gosta de legibilidade no código?

[Max Nunes]

Eu acredito que isto depende da necessidade. Por exemplo: 

Pode ser anonimo: carros só será utilizado para algum tipo de calculo ou tratamento dentro do mesmo método.

Precisará ser definido o tipo: carros será passado por parâmetro para outro método ou será o retorno do método atual.

Max Claus Nunes - Desenvolvedor e Analista de Sistemas

Em 7 de agosto de 2012 09:51, dm.ga...@gmail.com <dm.ga...@gmail.com> escreveu:

[dm.ga...@gmail.com]

Minha maior queixa nesse contexto que atrapalha para fazer refactory. 

Mas continua sendo até usável para coisas bem minusculas. 

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/8/7 Max Nunes <maxc...@gmail.com>

[Marcus Alexandre Silva]

Eu ja penso que se seu código chega a ser complexo o suficiente para
que um var atrapalhe a legibilidade, voce deve joga-lo fora e escrever
outro....

Em 7 de agosto de 2012 10:13, dm.ga...@gmail.com
<dm.ga...@gmail.com> escreveu:

[João Bateloche]

Ainda não vi nenhum exemplo, nenhum mesmo, onde o 'var' torna a leitura difícil. Quando eu encontrar posso falar qualquer coisa sobre legibilidade. O que vejo normalmente é o contrário.

O máximo que eu vi foi algo do tipo:

var a = Helper.GetBlaBlaBla();

Completamente ilegível, não da pra ter a menor noção do que está acontecendo, certo? Mas e se eu usar tipagem explícita?

String a = Helper.GetBlaBlaBla();

Que também é completamente ilegível.


Então dá pra dividir em dois casos, o primeiro onde o conjunto variável/objeto/método é bem nomeado e dá semântica à chamada, neste caso tanto faz.

O segundo, o método possui pouco sentido, neste caso quando usamos a tipagem explícita, diminuímos um pouco a ilegibilidade no código, mas continua não sendo o ideal, refatore o método de um jeito que ele diga o que faz e dê um nome melhorzinho à variável.

Poderia ter um terceiro que é o do exemplo acima...

A conclusão que consigo chegar é que em 90% dos casos a tipagem implicita não afeta negativamente o entendimento do código, e e nos outros 10 ela não ajuda em muita coisa.


Sobre o segundo comentário: O cara ser MVP não deve mudar a maneira com que você encara a resposta dele. Além do que, é impossível fazer qualquer tipo de comparação entre tipagem implicita e generics.

Na boa, quando usamos tipagem implicita, quem programa, quem lê o código e o compilador sabem o tipo que está sendo retornado, com generics, nós também sabemos, mas 'injetamos' o tipo no momento da criapção do objeto, então não há nenhum tipo de semelhança.

Em 7 de agosto de 2012 19:37, Paulo Morandi <psmo...@gmail.com> escreveu:

Vamos colocar mais lenha nessa fogueira então...

Do site da Microsoft ( http://msdn.microsoft.com/en-us/library/bb384061(v=vs.110).aspx ):

" However, the use of var does have at least the potential to make your code more difficult to understand for other developers. For that reason, the C# documentation generally uses var only when it is required. "

Do forum da MSDN (http://social.msdn.microsoft.com/Forums/en-AU/netfxbcl/thread/33e48531-d8e8-48a0-80fe-27948a5957e1):

"You should almost never use it outside LINQ and anonymous type declarations.

Too often it is abused into a form of Generics, which is what intended to do.

If you know the type, then specify the type.

If you use it because you are unsure of the type, and you might change it, then you need better architecture."

Não conheço o cara que disse isso mas ele diz na assinatura que é MVP. 

E discordo completamente de que se você faz isso: "A classe  =  new A(); " "você vai queimar no inferno seu redundante infiel"... mas se fizer "var classe = new A(); "  "você vai para o céu querido fiel". 

E eu tenho a impressão que o VAR foi criado com o intuito de ser extensivamente utilizado com LINQ e seus tipos anônimos, o uso fora disso seria uma extrepolação do conceito que eles tinha em mente quando criaram essa tipagem.

Mas quem sou eu.. sou apenas um ignorante burro que vai arder no mármore do inferno por cada vez que, vejam vocês, declarar uma variável explicitamente. Esses programadores .net não tem jeito mesmo..

[Daniel Moreira Yokoyama]

Vida longa aos MVP's.

A MS ainda falou do lance de legibilidade... e isso foi dito aqui... o que me faz achar engraçado até. Eu me sinto como naquelas empresas que as pessoas dizem: "não usamos lambda aqui pq algumas pessoas não entendem" ou ainda "stored procedures fazem o código ficar mais enxuto e aumenta o reaproveitamento".

Mas o MVP, cara... este é o cara. Ele falou que não e pronto. Não se deu ao trabalho de dar motivos, esclarecer razões, ele não falou sequer de legibilidade, pior... ele ainda falou que se você se ver usando por que não sabe que tipo vai obter, deveria rever seu código. É por isto que eu amo MVP's, quando penso que sou muito radical em desprezá-los, eles mesmos aparecem e me lembram que eu tenho motivo de sobra para ignorá-los completamente.

Se você acha que seu código é menos legível, não use var. Se um dia eu pegar o seu código, eu vou dar uma risadinha leve, e nem vou me dar ao trabalho de te xingar (pelo menos não pelo var), o Resharper resolve isso de forma muito rápida e simples pra mim.

Você não vai pro inferno. Isto pra mim não é religião. É uma questão de bom senso. Ninguém vai pro inferno se, quando o taxista disser: São Cinquenta, a pessoa responder perguntando: "Reais?". Não... não... isso não leva ninguém pro inferno. A gente só ri um pouco disso ali na hora. Não é o bastante nem pra virar piada pra contar pros colegas no almoço. Pode ficar tranquilo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 7 de agosto de 2012 19:37, Paulo Morandi <psmo...@gmail.com> escreveu:

Vamos colocar mais lenha nessa fogueira então...

Do site da Microsoft ( http://msdn.microsoft.com/en-us/library/bb384061(v=vs.110).aspx ):

" However, the use of var does have at least the potential to make your code more difficult to understand for other developers. For that reason, the C# documentation generally uses var only when it is required. "

Do forum da MSDN (http://social.msdn.microsoft.com/Forums/en-AU/netfxbcl/thread/33e48531-d8e8-48a0-80fe-27948a5957e1):

"You should almost never use it outside LINQ and anonymous type declarations.

Too often it is abused into a form of Generics, which is what intended to do.

If you know the type, then specify the type.

If you use it because you are unsure of the type, and you might change it, then you need better architecture."

Não conheço o cara que disse isso mas ele diz na assinatura que é MVP. 

E discordo completamente de que se você faz isso: "A classe  =  new A(); " "você vai queimar no inferno seu redundante infiel"... mas se fizer "var classe = new A(); "  "você vai para o céu querido fiel". 

E eu tenho a impressão que o VAR foi criado com o intuito de ser extensivamente utilizado com LINQ e seus tipos anônimos, o uso fora disso seria uma extrepolação do conceito que eles tinha em mente quando criaram essa tipagem.

Mas quem sou eu.. sou apenas um ignorante burro que vai arder no mármore do inferno por cada vez que, vejam vocês, declarar uma variável explicitamente. Esses programadores .net não tem jeito mesmo..

On Tuesday, August 7, 2012 7:10:12 PM UTC-3, Marcus Alexandre (Betim/Mg) wrote:

[Luiz Carlos Faria]

[OFF]

É vendo o nível da discussão que me desestimulo mais e mais a acompanhar qualquer thread do grupo. Acho que talvez seja esse o motivo para os assuntos interessantes terem deixado o grupo (lembro com saudade de 2009, por exemplo).  

Ah, também é um dos motivos para não comparecer aos eventos etc, mesmo sabendo que têm sido bem expressivos, mas poderiam ser mais...

Me desculpem, sei que nem todos compartilham desse pensamento, e que na verdade uma minoria é responsável por crises de stress e pancadaria pública. Eu realmente acreditava mais nisso aqui. 

Espero que alguém reflita e tome alguma ação: Moderação... etc.

Enquanto isso, vai continuar sendo um marcador no meu GMAIL, em que eventualmente esbarro por curiosidade.

[ ]s

_______________________________________________________________
Luiz Carlos Faria

[Victor Arias]

Daniel,

Você esta de parabens. Sua paciencia neste discussão é digna de um ser celestial.

[]s,

Victor Arias

[Luiz Carlos Faria]

Voltando ao ssunto principal, 

acho que já que eu me envolvi para expressar uma opinião pessoal, devo também, expressar minha opinião profissional, até porque o grupo foi destinato a este fim:

A utilização do "var " deve depender de:

1) Depende diretamente  da sua equipe.

2) Depende da necessidade de inspeção/validação

3) Depende da capacidade de criar códigos legíveis.

Acredito que muitos de nós, dependa não somente de IDE's para o DIA-a-DIA, acredito, que assim como eu, ferramentas de comparação (utilizadas para code review) sejam usadas o tempo todo ()via winmerge, tortoise merge, tortoise diff etc). É importante saber a procedência e o tipo do valor, seja por questões arquiteturais, ou até mesmo semânticas. 

: Na minha realidade, na maior parte dos casos, em que vejo uso indiscriminado do "var " sou obrigado a recorrer à IDE.

A relevância de se identificar o tipo de um resultado se mostra muito útil em aplicações baseadas que usam bind de objectos (seja ele no MVC, WCF, ou qualquer interface que permita binding de objetos sem existência de um schema, ou que o schema ainda seja ambiguo).

Na minha experiência, na maior parte do code code review, sempre que me gera uma dúvida, preciso visitar a IDE. Ou executar queries (próprias) no código para cachar o chamador etc etc.

Claro... um 'var nomeCoerente - new String("teste");' sequer pode ser chamado de má prática.

Então se fala sobre o que o Fowller diz, sobre o que o Resharper Prega... 

É isso mesmo? Vamos ignorar nossas experiências e entubar práticas sem avaliarmos seu valor?

Alguns podem entrar na discussão sobre times auto-gerenciáveis e arquitetura por meio do time: Por experiência própria: 10% do seu time será capaz de realizar qualquer mudanças estruturais na arquitetura. Dos 90% restantes, 30% serão apenas capazes de encontrar problemas, e 60% achará que há mágica para que "a coisa funcione". Sendo que nhao há código "externo" all source in solution.

Na minha experiência: o VAR é aplicável, mas sempre em que podemos, mesmo sem uso de uma IDE inferir ou obter o tipo do da variável.

Hoje sofro meio a um refactoring onde "vars" "indevidos", sob minha custódia julgá-los assim, atrapalham o desenvolvimento.

Vale lembrar que muitos Arquis/Devs não se preocupam com a manutenabilidade do código escrito e assim se preocupam somente com a V0... para podemos ter ganhos extremos com a V0. No entnato, manutenções subsequentes se mostram infuficientes  omeçamos a identificar ausência de informações que naturalmente teríamos.

_______________________________________________________________
Luiz Carlos Faria

[Marcus Alexandre Silva]

Victor,

Boa colocação.

Porém, eu entendo que, se você depender de maturidade de equipe para
aplicar algo que, ao meu ver é boa pratica, ela não vai
atingir maturidade nunca, ou pelo menos, vai demorar bastante.

Só que também você não precisa sair refatorando tudo, o tempo todo.

Na empresa onde eu trabalho foi adotada a convenção que o `var` esta
proibido de se utilizar no código da framework. Eu não concordei, até
fiz `biquinho`apelando, mas com o tempo acabei aceitando, afinal,
existem vários metodos que precisavam ser quebrados e refatorados
antes que as pessoas pudessem perceber os valores da utilização do
mesmo.

Em código macarrão, o var fica feio mesmo.

Este era o primeiro ponto, o segundo é, em código que esta funcionando
ninguém põe a mão se tiver outra coisa pra fazer, então, como sempre
temos outra coisa pra fazer, os refactories vão ficando para depois.
Estamos falando de um código com mais de 200.000 classes, uns 30
produtos diferentes sobre a mesma framework, migrado para .net entre
02~03.

Concluindo, onde eu não usaria var:
No que ja esta pronto e padronizado.
Onde eu usaria var: Em todo os outros cenários, menos os códigos que
eu precisaria trabalhar com doubles, longs e shorts (ai realmente fica
feio ficar misturando tipagem implicita e explicita no mesmo método).

Quanto as IDES, não sei porque não depender delaS, meu monodevelop que
estou usando deste mac que escrevo agora sabe trabalhar com o var
bonito... Realmente não sei porque diabos alguém desenvolveria no
bloco de notas atualmente....
Sobre MVP`s: Conheço muitos incrivelmente bons, não generalizem. Sobre
Re-Sharper: Até hoje não vi nada que não goste nele.

Nem 8, nem 80.

Marcus Alexandre

Em 8 de agosto de 2012 03:54, Luiz Carlos Faria
<luizcar...@gmail.com> escreveu:

[Francisco Berrocal]

Agora sim, prefiro o rumo que esta discussão está tomando, com argumentos mais técnicos, e menos pessoais.(Acredito ser mais produtivo)

Não só de MVPs se faz a referência contra os que são contra o uso abusivo do var.

http://www.voiceoftech.com/swhitley/index.php/2012/08/stop-using-var/  [Já citado no início do post]

http://msdn.microsoft.com/en-us/library/bb384061.aspx  [Já citado pelo Paulo Morandi]

http://www.codeproject.com/Articles/86224/Var-is-Bad 

http://www.nexustechnologiesllc.com/blog/var-is-bad/ 

http://richarddingwall.name/2008/06/21/csharps-var-keyword-jeff-atwood-gets-it-all-wrong/ 

http://weblogs.asp.net/stevewellens/archive/2009/11/19/can-the-c-var-keyword-be-misused.aspx 

Mas em contrapartida há algumas pessoas, que o usam abusivamente, como Scott Hanselman.

http://www.hanselman.com/blog/ 

Acho que o conhecem, e temos que concordar que no mínimo, ele é um bom programador.

Mas em quase todos os posts dele, se observarem as declarações, são usadas a keyword 'var'.

Na minha opinião, o 'var' pode ser usado, mas deve ser avaliado o contexto e controlado.(como dito antes)

Às vezes estamos tão certo das nossas opiniões, e queremos mudar a de outros, que não nos

tornamos receptivos à opiniões externas para analisar e avaliar.

Att,

Francisco Hisashi Berrocal

[Francisco Berrocal]

Quanto ao ReSharper, como disse no início da discussão a feature de recomendar 'var' a todas as declarações é configurável.

É importante notar que não podemos seguir todas as recomendações do ReSharper cegamente, como se fóssemos um robô.

Temos que analisar o contexto do erro/warning, e ver se é aplicável.

Por exemplo: Quando temos uma entidade:

public class CandidateEntity

{

    public virtual IList<GradeEntity> Grades { get; set; }

    public CandidateEntity()

    {

         Grades = new List<GradeEntity>(); 

    }

}

O ReSharper sugere: que tornemos a classe 'sealed' (virtual member call in constructor.)

Mas se você quer usar o lazy loading do entity framework isso não faz sentido.

Nada deve ser seguido cegamente, nem mesmo a feature para tornar as declarações do tipo var, 

apenas por ser o ReSharper que está recomendando.

[Fernando Mondo]

O Resharper tem razão neste caso, prorpiedade virtual não deve ser instanciada no contrutor de classe que possa ser herdada

Aqui na empresa é obrigatorio o a tipagem explicita em retorno de métodos pois existem métodos que não tem nomes muito expressivos.

Mesmo isso tendo solução, como os projetos são grandes tenho que seguir o norma.

Quanto aos links passados pelo Francisco, nenhum realmente me convenceu a não usar o var, todos tem exemplos muito toscos com problemas de design das classes.

Nas palavras de Kent Beck:

from "Intent Revealing Method Selector" in Kent Beck's "Smalltalk Best Practice Patterns":

Name your methods (and variables) based on the intent of the user (caller for methods). Describe the goal they would seek to fulfil, not the mechanism or algorithm used to fullfil it.

--

[Fernando Mondo]

Ah, lembrando que o var só funciona dentro de um escopo de método, então ele nunca estará longe da dua declaração (a não ser que você não saiba OOP) como no exemplo do  http://www.codeproject.com/Articles/86224/Var-is-Bad 

[Francisco Berrocal]

Veja bem fernando, não estou falando que o ReSharper está errado, apenas enfatizando o fato que temos que analisar o contexto,

algum iniciante em entity framework programando com ReSharper, poderia seguir a recomendação do ReSharper e tornar a classe

'sealed', esperando que o lazy load funcione.

[Daniel Moreira Yokoyama]

Se ele esbarrasse em algo que o Resharper atrapalhou, ele fatalmente ignoraria a orientação do resharper. Veja bem: por que o resharper o orientou a fazer algo que vai contra o verdadeiro intento.

Daí os níveis de warning do resharper. Existem coisas que ele até aceita, mas sublinha de verde te dando alguma recomendação. O que eu posso notar, pela minha experiência, é que 80% das vezes ele propõe alguma mudança óbvia que eu só não enxerguei por estar focado em alguma outra coisa. Os outros 20% das vezes, ele sugere algo que não faz sentido pra mim até eu descobrir que fiz merda em algum outro lugar.

Não dependa de ferramentas (como eu não dependo) pra fazer seu código funcionar. Mas agradeça a ajuda delas pra manter a qualidade do seu código (que funciona) refatorado FTW.

Não é a toa que FxCop e CodeMetrics são usados em scripts de build pra avaliarem um critério relativo de qualidade de código, e que o Resharper se baseia nestas mesmas normas pra te orientar a fazer um código de qualidade (sempre contando com o SEU bom senso, da qual ele é desprovido).

PS: Entre recomendações de MVP's, defesa de equipes que não evoluem e mal uso de ferramentas de refactoring, alguém ainda acha que tem algum motivo muito bom pra não usar var que não seja baseado no "porque eu não gosto"?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

--

[Rodrigo Vidal]

Olá pessoal, 

Isso é uma questão de Mindset. 

sou a favor da tipagem implicita onde quer que seja, e se seu código não pode ser entendido em virtude disso, é porque ele não está bom o suficiente. 

Programadores que utilizam Ruby, Python vão ainda mais longe utilizando resolução dinamica de tipo, e nao é por isso que deixam de entregar seus projetos. Linguagens com resolução estática decentes como Haskell, Scala, F#, inferem na maior parte dos casos, e no inclusive fora do escopo da função/método. Na minha opinião isso se tornará norma.

Fico triste quando os programadores tem preguiça de aprender qualquer coisa pouco mais rebuscada, quando o assunto é linguagens de programação, me parece que qualquer abstração pensada, é justificava para se escrever código boçal, em nome da "diminuição da complexidade", que só existe pela falta de conhecimento do programador que está lendo, seja referente ao código, aos nomes, ou ao mindset que está acostumado.

Abraço,

  Rodrigo Vidal

  www.rodrigovidal.net

[Thiago de Menezes Cristo]

Eu uso var o tempo todo...até o momento não achei uma razão para não usar. Alguns exemplos...

C#:

1 - 

var clientList = GetClientList();

Não importa o tipo de lista, mesmo, eu sei que é uma lista, sei iterar em listas e se alguém for ver o meu código daqui a 200 anos vai entender claramente que se trata de uma lista de clientes, saberá usá-la e modificá-la, pode inclusive trocar o retorno da função de List<Cliente> para uma ClientCollection (herdada de System.Collections.ObjectModel.Collection) que tudo continua funcionando na boa.

2 - 

var discount = GetDiscount();

Não importa o que discount é, mesmo....pq na linha seguinte eu já sei...

if(discount > 50).....

Qq programador, daqui a 200 anos vai saber que discount é um tipo numérico, vai no máximo passar o mouse por cima pra identificar qual o tipo exato.

Não há dificuldade nenhuma na manutenção desse código, o compilador ajuda se discount for decimal e tentar usá-lo como inteiro. Inclusive se em um momento no seu código vc usa discount como decimal e tenta usar como inteiro depois o erro está exatamente na mudança do tipo (dentro do mesmo sistema é claro).

JavaScript:

Tenho num sistema aqui a seguinte função genérica que valida o valor de um dado campo...faria alguma diferença tipar a declaração (se fosse possível)?

hasValidValue: function (element) {

    var elementValue = $(element).val();

    var patt = new RegExp(this.regex);

    return patt.test(elementValue);

}

E como disse o @marcioh...@gmail.com:

"Se legibilidade fosse problema, ninguém usava javascript, python, ruby... E convenhamos, ler código python é mole mole!"

@luizcar...@gmail.com, tudo bem? Tenho algumas dúvidas sobre sua resposta....

1 - Pq o uso do var depende da sua equipe? A equipe não entende para o que serve isso? Na primeira vez que vi ficou claro, e olha que nem programo a tanto tempo assim.

2 - Não entendi esse ponto "Depende da necessidade de inspeção/validação".

3 - Não entendi o que as ferramentas de comparação tem a ver com o uso ou não do var. Como trabalho em uma equipe pequena, o merge tem rolado fácil aqui...=)

4 - Quando vc diz bind de objetos quer dizer algo do tipo myDropDown.DataSource = GetDataTable()? Se sim, qual a diferença para var clientes = GetClients();...myDropDown.DataSource = clientes;? Concorda que se clientes não for um tipo possível de dar bind nem vai compilar?

5 - Pode nos dar um exemplo do que julga ser um "var" indevido?

6 - Sobre meus exemplos acima, vc pode apontar algum que fique complicado de dar manutenção?

Abs,

Thiago de Menezes Cristo

2012/8/8 Rodrigo Vidal <rodrigo...@gmail.com>

[ElemarJR]

Minha visão:

O que penso sobre "var" no C#

http://elemarjr.net/2012/08/08/o-que-penso-sobre-var-no-c/

Em sexta-feira, 3 de agosto de 2012 17h23min31s UTC-3, Francisco Berrocal escreveu:

Senhores, li um post do Shannon Whitley hoje:

http://www.voiceoftech.com/swhitley/index.php/2012/08/stop-using-var/

Realmente, cada vez mais vejo pessoas usando a expressão "var", que nada mais
é do que a tipagem implícita da variável declarada.
Na minha opinião, ainda é uma tipagem forte, porém não mais declarada, e só agrega benefícios na leitura do código.Mas Shannon Whitley diz que a expressão é para preguiçosos, e deveria ser evitada.(Acho ele até um pouco extremista e polêmico deste ponto de vista).

É importante citar também que plugins consolidados como o ReSharper trazem por default a declaração otimizada para o uso do var.(Configurável)
(http://stackoverflow.com/questions/1873873/why-does-resharper-want-to-use-var-for-everything)

E vocês o que acham deste modo de declaração? Afinal, o uso do "var" para declarar variáveis melhora a qualidade de entendimento do código?

[Gustavo Cruz]

Sensacional!

+1 Like!

2012/8/8 ElemarJR <elem...@gmail.com>

[Fernando Mondo]

Elemar, quanto ao seu Exemplo (porque não colocou aqui :P )

IFoo f1 = new SomeConcreteFoo();
var f2 = (IFoo) (new SomeConcreteFoo());


Quando é que alguém vai precisar de um código destes? se você está atribuindo explicitamente para uma classe concreta use a classe concreta então.


Interface deve ser usada quando não conhecemos o tipo de retorno.

[Daniel Moreira Yokoyama]

Preciso dizer que eu já precisei disto, e vou falar onde ( e aí sim entra o lance do programador preguiçoso ):

O visual studio tem o recurso chamado "Create from usage"... que é quando você consome um método que ainda não existe. Ao pedir pro visualstudio criar o método, ele infere os tipos que você coloca no argumento pra criar os parâmetros (tipos e nomes).

Se você quer agilizar a "cara" do método criado (principalmente fazendo testes) você é tentado a fazer isto que o Elemar exemplificou. Este foi o meu caso (o que eu achei, depois de um tempo, um verdadeiro sintoma de preguiça... e de preassumptions desnecessárias - pq isto deveria vir através de refactoring).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Eu dei uma resposta no Post do Elemar que achei importante replicar aqui para compartilhar. O comentário em questão foi uma resposta para um outro comentário (do João Paulo Melo) que disse que tipagem explícita, no mínimo, dificulta a compreensão do código e aumenta a entropia do design.

Segue minha resposta:

É isto que estou te dizendo: Não. Não torna o código mais difícil de ser compreendido. Você está falando de um apêgo que se obtém pelo costume de se acreditar que os tipos são importantes, como faziam os antigos que nomeavam suas variáveis com o tipo prefixado (intIdade, strNome).
Este apêgo foi se desgastando à medida que os programadores compreenderam o grande problema que isso trazia pra modelagem (cliente.StrNome = “Daniel”) então droparam o tipo do nome, e descobriram que isto não comprometia a compreensão do código.
Agora, outro apêgo precisa ser desfeito: o de acreditar que o tipo explícito na declaração aumenta a compreensão (como acreditava-se que o prefixo no nome também o fazia).
Além disto, eu considero este “quase nula entropia do design” um equívoco. Afinal, a tipagem explícita te impede de simplesmente alterar o tipo do retorno sem alterar o tipo explícito a menos que eles sejam compatíveis por herança. Ora, bem sabemos que existem tipos virtualmente compatíveis mas que não possuem relação de herança (como um List e um Array, que só compartilham a implementação de IEnumerable). Se você usar var num método que retorne List e, posteriormente, mudar o retorno deste método para Array de T, provavelmente seu código não sofrerá dano (quase nula entropia do design de fato, ou seja, menos trabalho pra manter aquilo funcionando).
Por outro lado, se ao invés de usar o var, você tipar explicitamente o List, ao mudar o retorno, o compilador lhe dirá que há um erro de tipagem mesmo que todo o resto do seu código seja compatível com os dois tipos (maior entropia do design, pois maior será o trabalho para manter aquilo funcionando).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

O ponto é que, no fundo, não existem (ou pelo menos não parecem existir, apesar de eu ter dito num post anterior que eu fazia isto) boas razões pra fazer este código.

Pois, independente do tipo concreto ou abstração... o que o método retornar é o que a referência vai ter na mão. Se o método retorna IEnumerable, a referência terá IEnumerable. Se o método retorna Array, a referência terá Array. What's the big deal?

Em que situação será útil a referência receber um tipo concreto do método, e guardar o tipo abstrato? Se o método devolve Array, qual a vantagem de tipar IEnumerable?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 9 de agosto de 2012 09:39, Bruno Brito <bhde...@gmail.com> escreveu:

Cara, abstrai o conceito.

Vou tentar refazer a leitura do exemplo, que alias, foi mto bom para demonstrar quando não utilizar.

IFoo f1 = GetSomeConcreteFoo();

var f2 = (IFoo)GetSomeConcreteFoo();


Nesse caso não sabemos qual o tipo exato da classe concreta que o método retornará.


E utilizar VAR fazendo cast no método não é legal.

[Thiago C. Santos]

Em que situação será útil a referência receber um tipo concreto do método, e guardar o tipo abstrato? Se o método devolve Array, qual a vantagem de tipar IEnumerable?

Se o valor recebido for usado como um parametro de um outro metodo por exemplo, e este parametro ter que ser IEnumerable, é totalmente coerente fazer isso.

Att,

Thiago C. Santos

2012/8/10 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Thiago C. Santos]

kkkkkkkkkkkkkkkkkkk, esquece esquece esquece

Att,

Thiago C. Santos

2012/8/15 Thiago C. Santos <thiago.c...@gmail.com>