Clique aqui para ler todos os artigos desta edição
A evolução das ferramentas de programação
Por Mauro Sant’Anna
Quando utilizamos um ambiente tão complexo como o Visual Studio .NET, temos a impressão de já foi feito tudo que o poderia ser feito para auxiliar o processo de programação. É claro que existem ferramentas de análise como as da Rational ou da Borland, mas elas não se concentram especificamente na programação. Isso nos dá a impressão de que atingimos o topo no que se refere a ferramentas de codificação.
Pois eu acredito que não, especialmente porque existem duas grandes áreas sujeitas a melhorias: “análise estática” e “refactoring”. Vou falar primeiro de análise estática. Existem certas técnicas de programação que são reconhecidamente ruins. Por exemplo:
· Uso de variáveis de instância quando apenas uma variável da função dá conta do recado;
· Uso de variáveis globais (public static no C# ou public shared no VB.NET);
· Uso de variáveis de instância públicas;
· Criação de funções muito grandes, com centenas de linhas de código;
· Atribuição de nomes inadequados às variáveis, como, por exemplo, “Temp1”, “xxa”, que não descrevem as variáveis;
· Uso de comandos de desvio, como GoTo;
· Falta de comentários.
Se essas técnicas são ruins, porque os compiladores as aceitam? A resposta é que nenhuma delas viola regras da sintaxe da linguagem, e pode ser até que sejam necessárias em um ou outro caso. Por causa disto, seu uso tem ficado a critério do programador.
Uma equipe de desenvolvimento pode melhorar a qualidade do código tomando duas providências:
1. Criando padrões de codificação;
2. Efetuando revisões periódicas que confirmem que os padrões estão sendo efetivamente seguidos.
A revisão de código é uma boa prática; um revisor atento pode até descobrir erros de lógica que nenhum compilador seria capaz de detectar. No entanto, as revisões sempre nos dão a impressão de que estamos fazendo manualmente algo que o compilador deveria fazer automaticamente.
Efetivamente, várias questões de revisão de código poderiam ser detectadas automaticamente com um compilador mais “esperto”. Felizmente, estão surgindo no mercado ferramentas de análise estáticas capazes de detectar codificação “questionável” e de economizar nosso trabalho durante a revisão.
Uma dessas ferramentas é o FxCop, da própria Microsoft (www.gotdotnet.com/team/fxcop/).
O FxCop trabalha diretamente sobre os assemblies (.EXE e .DLL), o que de cara já não lhe permite verificar algumas coisas que só existem no fonte, como a presença de comentários e os nomes de variáveis locais. Por outro lado, como a compilação de um programa .NET preserva muita informação como metadata, é possível fazer bastante coisa. Além disso, o FxCop não depende da linguagem usada originalmente e funciona igualmente bem com C# e VB.NET.
Tenho certeza de que outras ferramentas de análise desse gênero serão lançadas por vários outros fornecedores. Uma ferramenta que analise o programa-fonte pode também detectar outros tipos de problemas, como, por exemplo, a falta de comentários. Na verdade, podemos imaginar uma ferramenta que analise não só programas- fontes individuais como também projetos completos. Essa análise mais completa poderia detectar problemas como funções públicas não utilizadas em nenhum lugar do projeto, violação de regras de nomes para namespaces em relação aos assemblies, etc. Seguindo esta linha de raciocínio, podemos até mesmo imaginar ferramentas que renomeiem inteligentemente uma função não apenas na sua declaração, mas em todos os lugares em que ela é utilizada. Ou extrair um trecho de código como uma nova função. Ou encapsular um campo como uma propriedade.
Todas essas tendências nos levam às ferramentas denominadas “refactoring”, que ajudam a remontar inteligentemente o nosso código, como, por exemplo, a “Refactoring .NET” em “http://dotnetrefactoring.com/”.
Tenho certeza de que ainda veremos bastante evolução nas ferramentas de desenvolvimento.
