Um dos problemas mais comuns apontados pelo nosso amigo Sonar e a alta complexidade ciclomatica. E uma medida chata, muitas vezes dificil de diminuir. Mas para diminuir, antes e preciso enteder como essa complexidade e calculada! Na Wikipedia temos uma definicao bem simples e util, em resumo:A complexidade ciclomatica duma secao do codigo fonte e a quantidade de caminhos independentes pelo codigo. Por exemplo, se o codigo fontes nao contem estruturas de controle senao sequenciais a complexidade e 1, ja que ha somente um caminho valido atraves do codigo. Se o codigo possui somente uma estrutura de selecao contendo somente uma condicao, entao ha dois caminhos possiveis, aquele quando a condicao e avaliada em verdadeiro, e aquele quando a condicao e avaliada em falso.Ou seja, cada comando que provoca desvios, como if s e switch s, elevam a complexidade ciclomatica de um trecho de codigo. Por exemplo, o codigo abaixo possui complexidade ciclomatica igual a 1:public void metodo(String abc) { System.out.println(abc);}Ja o codigo abaixo teria complexidade igual a 2:public void metodo(String abc) { if ( condicional ) { System.out.println(abc); }}E com um simples e inocente switch? A complexidade vai ser igual ao numero de cases!!!double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() + getLoadFactor() * _numberOfCoconuts; case NORWEGIAN_BLUE: return (_isNailed) ? 0 : getBaseSpeed(_voltage); }}E esse (switch) e o caso mais perigoso! De maneira muito facil ele eleva drasticamente a complexidade ciclomatica.E por que se preocupar? Porque quanto maior a complexidade maior vai ser a probabilidade de erros, maior a necessidade de testes (o ideal e que o numero de testes fosse igual ao numero da complexidade) e, principalmente, maior a probabilidade de alguem que estiver lendo ou alterando o codigo (manutencoes) perder algum detalhe importante. Ou seja, maior probabilidade de bugs e menor produtividade. Complexidade Classificacao Entre 1 e 10 Baixa complexidade. Facil entender e testar. Entre 11 e 20 Media complexidade. Relativamente dificil entender e testar. Entre 21 e 50 Alta complexidade. Dificil entender e testar. Maior que 51 Altissima complexidade. Impossivel entender e testar.Mas o que fazer? Parar e pensar! Sera que nao podemos utilizar alguma outra alternativa? Que tal polimorfismo?Ou quem sabe um strategy? O importante e nao fugir muito da borda.Ate! Recentemente fui implantar um sistema que utiliza Spring 3, JPA 2 e PrimeFaces 3 na Integrator.com.br, ate ai nada de mais, a nao ser por uma restricao do Integrator de nao permitir que o Spring criasse o datasource, ele deveria ser criado pelo Tomcat.Nada muito complexo tambem, no Spring basta declaramos um bean que apontara para o endereco JNDI do datasource a ser criado no Tomcat, algo assim: Feito isso, basta criar o datasource no Tomcat. Para isso, precismos criar um arquivo XML com o mesmo nome da sua aplicacao, vamos dizer que a aplicacao no caso vai ser a "exemploApp", logo o arquivo a ser criado sera o "exemploApp.xml". Neste arquivo configuraremos o datasource, algo assim (no exemplo e um banco Mysql): Observe que o nome JNDI utilizado pelo bean do Spring e o mesmo para o datasource (name="jdbc/NomeQualquer").Esse