EVGD: Códigos Toscos

Ele até fez Sombreamento sem querer!

AUHUAHuAHuAHuAHUAuAHAUHAUhAUhA

Exercicio2 então isso é normal hahahahhahaha

Olha… pelo menos esse cara aprendeu para que serve o if =)
Ele pode evoluir para if / else, switch, uma lista de dias indexada, polimorfismo, etc.

Pior é ver esse tipo de código para coisa mais séria.

Me lembro de um programa em pascal cheio de ifs aninhados pq eu não conhecia AND e OR :confused:

Ah, as primeiras aulas de programação… a gente era feliz e não sabia…

Grandes DBAs:

SELECT A.* FROM TABELA_LEGAL A WHERE TO_DATE(A.DT_INICO_VIGEN,'dd/mm/YYYY') <= TO_DATE(SYSDATE,'dd/mm/YYYY')

E ai matam os índices, performance e o banco.

Iterator, for… pra que servem?
Nããããão, vamos engessar por índice mesmo:

public void atualizarAntigoAtualizarNovoXpto(List listaXpto){ bean.atualizarXpto( (Xpto)listaXpto.get(0)); bean.atualizarXpto( (Xpto)listaXpto.get(1)); }

Ou se a idéia é fazer exatamente dois, então passe dois parâmetros.

Sem comentários…

    // verifica o destino
    String acao = request.getParameter("acao");
    if (acao == null)
	     acao = "";

if (acao.equals(""))
{
	// pra não dar erro na primeira vez que abre...
} else if (acao.equals("carregar_projeto"))
{

} 
// e uma cadeia de if´s e else

Eu já fiz isso :X

quando eu li, não pude deixar de postar aqui…

Olha o que os caras estão fazendo pra pegar o MAX de uma coluna na tabela

int cont = 0;
try{
setSql("SELECT * FROM Est WHERE est=?");
ps = conn.prepareStatement(getSql());
ps.setString(1, getEst());
rs = ps.executeQuery();
while(rs.next()){
if(cont < rs.getInt("colunast"))
cont = rs.getInt("colunast");
}
}
catch(SQLException ex){
ex.printStackTrace();
}

aqui: http://www.guj.com.br/posts/list/107335.java

Por causa de um search errado, pensei que esse método era chamado em várias pártes do código. Fiquei imaginando qual a gambi que a JVM ou o compilador estaria fazendo pra lidar com isso:

	public void update() {
		this.update();
	}

esse código e o mais tosco que ja vi

if (1==1){
//Exibe formuláriod e de crédito de clientes

}

//Pula 3 linhas. for(i=0; i<3; i++) System.out.print("\n");

Programação absolutista:

int answer = JOptionPane.YES_OPTION;
if (answer != JOptionPane.YES_OPTION)...

Ontem eu estava vendo um código de uma stored procedure, e numa parte do código estava assim:

/* Código temporário para processamento de XXXXXX /* código pl/sql

Aí um amigo meu que estava no meu lado falou: Cara, pode ter certeza que toda vez que você vê num código esse tipo de comentário (código temporário), pode ter certeza que isso ficará pra sempre assim.

E o pior é que ele tinha razão.

Isso que ele tem 19 anos e já tá no esquema.

Vivendo e aprendendo.

EDIT:

[quote=renato3110]Por causa de um search errado, pensei que esse método era chamado em várias pártes do código. Fiquei imaginando qual a gambi que a JVM ou o compilador estaria fazendo pra lidar com isso:

	public void update() {
		this.update();
	}

Esse é o algoritmo recursivo mais tosco que eu já vi :lol:[/quote]

Não sei se tu sabe, mas no próprio código da JDK tem esse tipo de recursividade. Se você fala isso de um código simples, aposto que se você visse o código da JDK provavelmente já teria feito chapinha no cabelo, pintado o olho e com uma gilete cortando os pulsos

Como assim no JDK??? se você chamar um método desse dá StackOverflowError!

amigo, eu estou em referindo ao CÓDIGO FONTE da JDK :stuck_out_tongue:

existe método lá (que por sinal, escrito pelo próprio Joshua Bloch) que é certeiro que vai dar um StackOverflowError :stuck_out_tongue:

if (true) { . . .[i] (+1000 linhas de código)[/i] . . . } else { System.out.println("fudeu"); }
Realmente se algum dia eu ver fudeu no console é porque fudeu mesmo! :roll:

try { . . .} catch(Throwable t) { System.out.println("Falha de integração com o SICO"); }

Por algum motivo o sistema SICO sempre foi o culpado dos bugs do sistema, uma idéia muito inteligente por sinal. :wink:

[quote=Leozin]amigo, eu estou em referindo ao CÓDIGO FONTE da JDK :stuck_out_tongue:

existe método lá (que por sinal, escrito pelo próprio Joshua Bloch) que é certeiro que vai dar um StackOverflowError :P[/quote]

Poderia mostrar um?

[quote=renato3110][quote=Leozin]amigo, eu estou em referindo ao CÓDIGO FONTE da JDK :stuck_out_tongue:

existe método lá (que por sinal, escrito pelo próprio Joshua Bloch) que é certeiro que vai dar um StackOverflowError :P[/quote]

Poderia mostrar um?[/quote]

Eu olhei denovo aqui e não achei o que eu tinha visto uma vez…

mas achei esse aqui:

final protected void doRename(Name oldname, Name newname) throws NamingException { if (!setupMode) { throw new SchemaViolationException("Cannot rename a schema object"); } else { doRename(oldname, newname); } }

Fonte: com.sun.jndi.ldap.LdapSchemaCtx.java, linhas 143 à 150

Vou fazer uma pergunta indiscreta - que software você usou para determinar que um método é infinitamente recursivo? É que olhar os fontes do JDK é barra pesada, é coisa demais.

[quote=Leozin][quote=renato3110][quote=Leozin]amigo, eu estou em referindo ao CÓDIGO FONTE da JDK :stuck_out_tongue:

existe método lá (que por sinal, escrito pelo próprio Joshua Bloch) que é certeiro que vai dar um StackOverflowError :P[/quote]

Poderia mostrar um?[/quote]

Eu olhei denovo aqui e não achei o que eu tinha visto uma vez…

mas achei esse aqui:

final protected void doRename(Name oldname, Name newname) throws NamingException { if (!setupMode) { throw new SchemaViolationException("Cannot rename a schema object"); } else { doRename(oldname, newname); } }

Fonte: com.sun.jndi.ldap.LdapSchemaCtx.java, linhas 143 à 150[/quote]
Se ele rodar em um thread separado acho q não há stackoverflow.