Complete a frase: "Todo programador Java ruim que eu conheco..."

JavaTeenager Membro desde: 08/11/2007 13:34:45 Mensagens: 156 Offline

Todo programador Java ruim que eu conheco... nunca usa @deprecated

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 2928 Offline

fantomas wrote:

lina wrote:É claro que muitos métodos dessa classe já nem são mais utilizados. Falta tempo para uma revisão.
A classe foi sendo feita e agora não tem mais como estrutura-la para uma arquitetura melhor. Ela se tornou um "Deus" do sistema.. rs

Todos os método são de filtragem e etc... e alguns importantíssimos para o funcionamento geral do sistema. Ula-lala!

Kill me!

Só falta vc dizer que são geradas várias instancias deste Godzila.

É este tipo de coisa que arreg@#@ a imagem do Java.

Sabe quando o GC tira um monstro destes da memória?
R: N U N C A!

Aí vem o Zé dizer..."O Java ocupa muita memória!".

Get the hell out of here!

flws

Oi,

Não tenho problemas de memoria. Não tenho problemas com GC. E não estou arrg@#@ a imagem do Java.
Simplesmente quando entrei na empresa já estava assim.

Não é só no Java, como em todas as linguagens. O sistema está rodando a quase 5 anos sem problemas... e datelhe: Utilizando essa classe de varias linhas.

Tchauzin!

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

Ataxexe wrote:

lina wrote:Oi,

Por incrível que pareca, são métodos excelentes e com nível alto de programação!
Agora que minha maquina de desenvolvimento é boa, o eclipse não trava mais! rs

Tchauzin!

Se quiser trocar pelas 3000 linhas de resultado de um processo de digestão bem feita eu agradeço!

Tem método aqui que só a assinatura tem 15 linhas e os parâmetros são arrays de String.

Socoooooorro!!!

O engraçado é reparar a lista de importações da classe, certa vez contei e deu mais de 50 linhas só de importação!! (isso porque tinha uns import javax.something.* no meio).

lina wrote:Não tenho problemas de memoria. Não tenho problemas com GC.

Você não tem, mas outros mais bobinhos utilizam isto como argumento negativo sem antes analisar os detalhes.

lina wrote: E não estou arrg@#@ a imagem do Java.

Eu não quiz dizer isto, mas se ficou entendido assim desculpe.

lina wrote: Simplesmente quando entrei na empresa já estava assim.

Já vi este filme várias vezes, infelizmente isto acontece. Mas eu sempre aponto a deficiencia falando sobre a necessidade de um projeto de melhoria.

lina wrote: Não é só no Java, como em todas as linguagens.

Isto acontece porque um bando de displicentes que programavam em outras linguagens migraram para o Java trazendo seus POGs malditos.
Linguagem não é desculpa para péssimos hábitos de programação; a maioria das boas práticas que são ditas hoje, já foram ditas nos anos 80 talvez antes.

lina wrote: O sistema está rodando a quase 5 anos sem problemas... e datelhe: Utilizando essa classe de varias linhas.

Conheço várias empresas nesta situação; inclusive em uma delas o sistema (que possue classes enormes) está a 10 anos ou mais funcionando. Isto é bom? Pergunte para quem começa hoje e tem que fazer uma manutenção rápida e critica.

Os únicos que gostam desta sistuação são aqueles que já se acostumaram com o contexto, afinal o problema só pode estar em uma ou duas classes gigantes né!

Os coboleiros tambem (nem todos) faziam este tipo de coisa e diziam "Em Cobol é assim, além do mais está funcionando!"; acho que eles tinha medo de utilizar a "LINKAGE SESSION" ou não sabiam que o recurso existia.

flws

Debugger Membro desde: 02/05/2010 03:01:47 Mensagens: 66 Offline

Todo programador Java ruim que eu conheco...
Critica programas alheios pelo simples fato de terem sido desenvolvidos de forma diferente do que eles fariam.

...
cria uma variável ou objeto importantíssimo dando o nome dela de "i"

.... usa DEFAULT TABLE MODEL! HUAhuahuahuahu

em um outro tópico axei isso, foi a coisa mais feia que eu já vi! huAHUhuahua

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

flaleite wrote:Todo programador Java ruim que eu conheco...
....trata todas as exceptions dessa forma:
try { ... ... } catch (Exception e) { e.printStackTrace(); }

Tratar excessões é muito chato. Primeiro porque quase nunca elas são recuperáveis. E segundo que não há muito o que se fazer mesmo. O mais interessante é o registro de logs, mas é uma estratégia que depende mais do desenvolvedor senior (arquiteto) defini-la e não do jr para cada bloco de captura inventar coisas mirabolantes.

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

c354r wrote:Todo programador Java ruim que eu conheco...
Critica programas alheios pelo simples fato de terem sido desenvolvidos de forma diferente do que eles fariam.

EU critico software corporativo mal projetado porque um dia eu posso cair na manutencao dele. Pq nao? Só Deus sabe... hehehe

Até pq ja trabalhei com manutencao há muito tempo, inclusive com PHP, e sei o que é o inferno.

Lina nao seria má idéia vc informar a empresa que trabalha pro pessoal ficar esperto e ter um nivel de informacao melhor antes de tomar certas decisões ...

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1838 Offline

Se tem uma exceção e nao sabe o que fazer com ela.. deve se jogar pra frente..
Então, não se deve fazer isso:

E sim (na pior das hipóteses):

... ao inves de verificar se o objeto é nulo faz:

Uma nova versão do tradicional catch todas as exceções (pra mim, o pior tipo)

Fico pensando o que um POGger desses tinha na cabeça.... Pior é que as vezes ocorria uma exception aqui... e pra achar... O sistema ficava inconsistente mas não havia nem um StackTrace pra olhar.

E mais essa:

wellington.nogueira wrote:... ao inves de verificar se o objeto é nulo faz:

try { algo = objeto.getAlgo(); } catch(NullPointerException e) { objeto = new Objeto(); algo = objeto.getAlgo(); }

Ainda que ai fazem assim e eu q já peguei boas gamas de classes assim:

Vários try fazendo funções de comparação e catchs vazios...

Vi algo que me faz ressucitar este tópico...

Obs.: condicaoN() e doCondicaoN() são apenas simplificações, não os métodos reais

Não sei o NetBeans, mas o Eclipse pelo menos ia falar que aquilo é dead-code e não deixa nem compilar.

Marky.Vasconcelos wrote:} else if(true) { //<-- O que é isso???!!!! doCondicao3(); } else { doCondicao4(); //Será que executa? hehehehe }

Não sei o NetBeans, mas o Eclipse pelo menos ia falar que aquilo é dead-code e não deixa nem compilar.

Essas coisas dependem de configuração mas garanto que isso foi feito no Eclipse

Dead-codes aqui só os pós-return e mais um ou outro ponto que não lembro mas esse... certamente está passando.

PS: o doCondicao3 nada fazia

Notícias, artigos e o maior fórum brasileiro sobre Java