God bless Eclipse

hehehehehehhee

o segundo código foi o mais comédia :lol:

e claro, God bless Eclipse

Parece aqueles codigos que sobram apos varias manutencoes e “evolucoes”…

Marcio Kuchma

danieldestro:

Hoje peguei uma aplicação que uns colegas fizeram e me deparei com muita bizarrice.

Acho que vc é mais amigo deles do que eles de vc :mrgreen:

Aí, usou o que no Eclipse pra achar essas pérolas?

Se não me engano os “feras” usaram o JEdit para fazer o código. Só criei um projeto no Eclipse e tcha-nãmmm…

Falei uma vez, mas merece ser repetido…

public class Eclipse extends God

Bom, se puser os plugins do Checkstyle, PMD e FindBugs acho que vai achar mais coisas ainda (talvez coisas demais). Um projeto pequeno com código perfeitamente razoável pode ter 9000 ou 10000 warnings e errors do Checkstyle, o que pode deixar qualquer um louco.

Há um monte de coisas polêmicas nos settings default do Checkstyle e PMD (tais como o fato de que eles insistem em forçar que parâmetros de métodos devem ser declarados como ‘final’, ou que você nunca deixe tratamento de exceção em branco - mesmo naquele caso “try { conn.close() } catch (SQLException ex) {}” que todo mundo faz quando usa JDBC ) que podem obscurecer o fato que muitos dos warnings apontados em código comum são realmente dignos de serem corrigidos.

Todo mundo faz isso mas não deveria. SQLException no close é uma boa forma de verificar se o banco tá em sérios apuros.

Sim… e eh meio xarope desabilitar as regras no plugin Eclipse… :?

Coisas como ter apenas um return, tamanho dos nomes das variaveis, etc, as vezes irritam… mas no geral esses plugins sao muito bons…

Marcio Kuchma

Quem é obrigado a usar esses plugins acaba aprendendo algumas regras para enganá-los.

Regra: Não use System.out.print ou System.out.println em componentes
Como enganar: A regra foi mal-programada (ela procura a string “System.out.print” dentro de seu programa, usando uma procura simples de string. Se você deixar isso dentro de um comentário, ela acha dentro do comentário. Se você usar “System .out . print” com um espaço antes do ponto, ele não acha e não reclama.

Regra: Toda rotina deve ter apenas um return.
Como enganar: Você deve conhecer um recurso pouco explorado da linguagem que é o “label” e o “break”. O “Label” é uma forma controlada de você fazer um “goto”. Por exemplo:

fim: {
    linha1();
    linha2();
    if (condicao1()) {
        break fim;
    } 
    linha3();
}
linha4();

“break fim” irá desviar a execução para a linha4() quando for executado.
Para enganar a regra do return, declare uma variável com o tipo adequado para o retorno da função. Nos lugares onde existia "return valor; " e o plugin reclamava, substitua por “ret = valor; break fim;” E no fim da função, use então o único return, “return ret;”

Assim você não terá de deixar seu código incompreensível, só para tentar não violar a regra de “um único return”.

Não sei se isso funciona, mas acho que engana também:

System.out .println("Minha string");

[]'s

Por favor não… goto é a morte.

Eu programo em Cobol e tento fugir deles, mas é quase impossível.

No caso de vários returns eu prefiro fazer assim:

if (x == 1)
  retorno = 1;
else if (x == 2)
  retorno = 2;
else if (x == 3)
 retorno = 3;

return (retorno);

Assim eu acho que fica menos porco que com goto… Se é que assim fica ruim.

O melhor mesmo eh desabilitar essa regra no plugin, quando possivel. Mas com o tempo acho que esses plugins vao evoluir, tornarem-se mais “gerenciaveis” e esse tipo de problema acabara.

Ter que fazer gambiarra para evitar um puxao-de-orevlha da ferramenta eh dose.

Marcio Kuchma