Arquivo

Textos com Etiquetas ‘CSharp’

[InfoQ] C# 5.0 terá sintax sugar para operações assíncronas

4 de novembro de 2010

O time de desenvolvimento de .NET da Microsoft anunciou nessa última semana que a próxima versão da linguagem C# terá uma nova sintaxe, mais enxuta, para realizar operações assíncronas.

Atualmente, para realizar uma tarefa assíncrona é necessário utlizar callbacks, seja declarando métodos separados ou utilizar métodos anônimos.

No C# 5.0, com a utilização dos novos comandos async e await, essa tarefa ficará muito mais fácil de escrever.

Veja a notícia completa na InfoQ Brasil:
http://www.infoq.com/br/news/2010/11/csharp-5-sintax-sugar

Veja também outras notícias e artigos sobre .NET na InfoQ Brasil:
http://www.infoq.com/br/dotnet

.NET , , , ,

Desprenda-se de convenções de nomenclatura em nome de testes

21 de novembro de 2009

Eu compartilho da opinião de Jimmy Bogard, que diz que os nomes dos testes precisam descrever o que e o porque, a partir da perspectiva do usuário, onde o desenvolver possa ler o nome do teste e claramente entender o comportamento que é esperado.

Um teste unitário nada mais é que um método em uma classe, e tanto em C# como Java, existem convenções de nomenclatura de métodos.

Em C#, nome de métodos são declarados utilizando Pascal Case:

[TestMethod]
public void ProductShouldHaveAtLeastOneCategory()
{
  //Test implementation.
}

Já em Java, convencionou-se escrever métodos utilizando Camel Case:

@Test
public void productShouldHaveAtLeastOneCategory() {
  //Test implementation.
}

Muitas vezes, o nome desses testes (métodos) ficam um tanto longos, como os exemplos acima. Dessa forma, a legibilidade não é muito boa.

Seguindo um dos conselhos de Neal Ford, em sua apresentação 10 Ways to Improve Your Code, você pode deixar de lado as convenções de nomenclatura da linguagem em favor da legilidade dos nomes dos seus testes. Escreva o nome do teste como se fosse uma frase, nada de letras maiúsculas para cada palavra, e use “_” (underscore) para separar as palavras.

Veja como fica o exemplo acima em C#:

[TestMethod]
public void Product_should_have_at_least_one_category()
{
  //Test implementation.
}

E agora em Java:

@Test
public void product_should_have_at_least_one_category() {
  //Test implementation.
}

Não há nenhum mal em se desprender das convenções de nomenclatura de C# e Java em prol da legibilidade dos nomes dos testes. Afinal, testes são uma documentação executável e nós queremos uma documentação clara para nosso código.

TDD , , , , , , ,

[Tradução] Qual é a diferença entre os operadores “as” e “cast”?

29 de outubro de 2009

Muitas pessoas lhe dirão que a diferença entre “(Alpha) bravo” e “bravo as Alpha” é que o primeiro lança uma exceção se a conversão falhar, enquanto que o segundo retorna null. De qualquer forma isso é correto, e isso é a diferença mais óbvia, mas não é a única diferença. Há armadilhas para se tomar cuidado aqui.

Primeiro, desde que o resultado do operador “as” pode ser null, o tipo do resultado precisa ser um dos que aceitam um valor nulo: um tipo referência ou tipo valor nullable. Você não pode fazer “as int”, isso não faz sentido. Se o argumento não é um int, então qual valor de retorno deveria ser? O tipo da expressão “as” é sempre um tipo nomeado, então ele precisa ser um tipo que pode receber null.

Segundo, o operador cast, como eu discuti antes, é uma besta estranha. Ele significa duas coisas contraditórias: “verifique para ver se o objeto realmente é desse tipo, lance uma exceção se não for” e “esse objeto não é do tipo informado; encontre um valor equivalente que pertença ao tipo informado”. O segundo significado do operador cast não é compartilhado pelo operador “as”. Se você diz

short s = (short)123;
int? i = s as int?;

então você está sem sorte. O operador “as” não fará conversões “representação-substituição” de short para int nullable como o operador cast faria. Similarmente, se você tem uma classe Alpha e uma outra classe não relacionada Bravo, com uma conversão de Bravo para Alpha, então “(Alpha) bravo” será convertido, mas “bravo as Alpha” não. O operador “as” apenas considera conversões de referência, boxing e unboxing.

E finalmente, é claro que o uso dos dois operadores são superficialmente similares, mas semanticamente completamente diferentes. O cast comunica para o leitor “Eu estou certo que esta conversão é legal e eu concordo em receber uma exceção se eu estiver errado”. O operador “as” comunica “Eu não sei se esta conversão é legal ou não; nós vamos tentar e ver o que acontece”.

Esse texto é uma tradução do post original que Eric Lippert, engenheiro de software da Microsoft, publicou no seu blog Fabulous Adventures In Coding. A versão original você pode ler aqui.

Observação: Essa é minha primeira experiência em tradução de artigos técnicos. Seu comentário expressando sua opinião a respeito é muito bem vinda.

.NET , , , , , ,

Cheeseburgers, Decorators e Mocks

29 de julho de 2009

Em São Paulo, eu sempre comi cheeseburgers feitos com pão, hamburguer e queijo. Mas quando eu fui para Itararé, cidade do interior do estado de São Paulo, descobri que eles também colocavam milho no sanduíche.

Para exemplificar, vamos imaginar que o cheeseburger de Ilhéus-BA, venha com molho de pimenta. Só para constar, eu nunca fui para Ilhéus, apesar de ser a cidade natal de meu pai. Então na verdade não tenho a mínima idéia de como seja o cheeseburger de lá.

Imagem original de MarketFare Foods, Inc.

Imagem original de MarketFare Foods, Inc.

Vamos transportar esses três tipos de cheeseburgers para objetos e fazer alguns testes com eles. Usarei como plataforma .NET, linguagem C#, a ferramenta de testes unitários que vem com o Visual Studio 2008 e o Rhino Mocks como framework de criação de mocks.

Leia mais…

.NET, Arquitetura , , , , , , , , , , , , ,