Ontem a tarde a Microsoft anunciou uma atualização para o C#6 e para Roslyn (agora conhecido como .NET Compiler Platform), juntamente com o primeiro preview do Visual Studio 2015.

Enquanto eles se preparavam para esse anúncio, alguns amigos e eu participávamos do MVP Global Summit, em Redmond, lá com a Microsoft. Durante o evento tivemos a chance de nos interarmos mais das APIs do Roslyn, e do compilador do C# em si. Codamos lado a lado com o time do C#, criando analisadores e corretores de códigos (code fixes). O que fizemos foi criar refatorações (por exemplo, utilizar um object initializer quando possível), avisos de possíveis problemas (exemplo: você está usando um nome fora do padrão pra uma determinada classe), entre outros.

A API do Roslyn permite analisar a árvore sintática do código, incluindo outros detalhes interessantes, como trivias (espaços em branco, etc), e fazer uma análise semântica. É extremamente expressiva e precisa de utilizar, é um prazer codar com ela. E possui suporte completo para testes de unidade em memória, o que torna o processo de desenvolvimento rápido.

Quando o Roslyn surgiu e eu vi o que a API conseguiria fazer, eu tive a ideia de criar um projeto para agregar contribuições desse tipo. Só faltava o empurrão. Enquanto estávamos lá eu sugeri a ideia, e logo o pessoal comprou. Foi assim que nasceu o  Code Cracker. O Elemar Jr de cara se comprometeu a entregar dois analizadores/code fixes por semana, no que eu equiparei: faria o mesmo. Ao fim do dia, tínhamos um monte de analisadores funcionando, cada um o seu, tudo muito desorganizado. Conseguimos montar nosso código inicial em uma hora, e ficamos o resto do dia aprendendo as APIs do compilador. No fim do dia criei o projeto, e o Elemar logo enviou o seu primeiro analizador.

O potencial do projeto é gigantesco, em um ano teremos mais de cem novas análises e code fixes, totalmente gratuitos, livres para quem quiser utilizar.

De lá pra cá temos evoluído o projeto. Junto com o Vinicius Hana, ainda no aeroporto voltando pro Brasil evoluímos a estrutura de testes. Ontem pela manhã estruturei o Nuget, e após o anúncio do novo .NET e do update do Roslyn, atualizamos o projeto. Ainda há muito trabalho a ser feito, mas a base está lançada. Nesse momento estou revisar olhar um pull request do Hana. No time core temos também o Carlos dos Santos.

Ok, o projeto está andando. Mas afinal, o que são esses tais analisadores? Melhor mostrar do que descrever.

Aqui temos o primeiro que escrevi. Como todos sabemos, rethrow de exceções é uma péssima ideia, porque o stack trace é perdido. Pra evitar isso, fiz um analisador (código aqui). Ele primeiro avisa do problema (clique para ampliar):

Você pode optar por corrigir o problema lançando a exceção original como inner exception (também com o teclado usando a mesma tecla de sempre: ctrl .), e ele vai te mostrar como o código vai ficar. Na prática o analisador já rodou e mostra como seria a mudança caso você a efetive (código do code fix aqui):

Ou corrigir de outra forma, somente com throw, que não altera o stack trace:

E por fim, com a mudança concluída:

Aqui temos um caso feito pelo Elemar, ele pegou o caso de uma ArgumentException lançada sem mencionar um parâmetro correto (analisador aqui):

Aqui a correção, notem como o code fix percebeu que há dois parâmetros e oferece qualquer um dos dois para corrigir (code fix aqui):

O projeto tem um bom readme na sua home, vale a pena ler pra entender. Temos também nosso backlog no Huboard, onde você pode ver o que está planejado, e os requisitos que já estão prontos.

Você já pode utilizar o CodeCracker com o Visual Studio 2015. Basta instalar o Nuget, que nesse momento é o Alpha 1 rodando “Install-Package CodeCracker” ou utilizando a janela do Nuget no próprio VS 2015.

Estamos “contratando” contribuidores Open Source.

Se você tiver interesse em participar do projeto queremos muito sua ajuda. Temos espaço para codar, para ajudar com a documentação, para dar ideias no issues, enfim há espaço pra ajudar. Entre em contato!

Se for codar, estamos usando Pull Requests. Fique atento com as as dicas de contribuição:

• Pull Requests devem ter testes de unidade. Sem testes o PR será rejeitado de imediato.
• Deve buildar e testes passarem.
• Deve mencionar o issue do Github que o PR resolve.
• Não reformate código que você não está criando ou alterando.
• Siga os padrões do projeto

Pretendo gravar um Tecnoretórica discutindo o processo de criação desse código. Além disso, vou seguir numa série de posts sobre o assunto. Os restante do time também, então fique atento.

Toda ajuda é bem vinda. Esse projeto é da comunidade. É nosso! E é super divertido de se trabalhar.

Experimentem, mandem críticas e sugestões. O que acharam?

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.