Ele até fez Sombreamento sem querer!
AUHUAHuAHuAHuAHUAuAHAUHAUhAUhA
Exercicio2 então isso é normal hahahahhahaha
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
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();
}
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
existe método lá (que por sinal, escrito pelo próprio Joshua Bloch) que é certeiro que vai dar um StackOverflowError
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.
[quote=Leozin]amigo, eu estou em referindo ao CÓDIGO FONTE da JDK
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
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
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.