EVGD: Códigos Toscos

Jose111 wrote:WTF !!!!

aplica o plural

Onde é utilizado aquilo?

Já precisei criar um código pra aplicar plural, num gerador de código.

Bruno Laturner wrote:

arthurminarini wrote:conheço um programador que gosta de nomes bem intuitivos. É SERIO MESMO NÃO É ZUAÇÃO

if (loginBlz) { blzPodePassar = true; sairAtualizandoMensagemQueFoiMostradaAUmTempoAtras(); }

Corrigido:
if (loginBlz) { blzPodePassar = true; sairAtualizandoMensagemQueFoiMostradaHaUmTempoAtras(); }

Na verdade, o erro apenas piorou. 'há' um tempo 'atrás' é pleonasmo.

O correto seria:

Ou

luistiagos wrote:quem não lembra da velha gambi para fazer muitas vezes sqls dinamicos?

where 1 = 1

Não consideraria isso uma gambiarra. É apenas um meio de tornar um código menos condicional. Agrega-se a isso o fato de '1 = 1' ser uma expressão que os SGDB's normalmente já são capazes de desconsiderar e, ainda que 'resolvam' a condição, o envolvimento na operação seja totalmente ignorável.

No caso de um SQL dinâmico (independente à existência de Hibernate ou de quaisquer frameworks e afins), como seria o correto*?

*sendo, para fins de explicação, 'correto' o antônimo de 'gambiarra'

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

Yky Mattshawn wrote:

luistiagos wrote:quem não lembra da velha gambi para fazer muitas vezes sqls dinamicos?

where 1 = 1

Não consideraria isso uma gambiarra. É apenas um meio de tornar um código menos condicional. Agrega-se a isso o fato de '1 = 1' ser uma expressão que os SGDB's normalmente já são capazes de desconsiderar e, ainda que 'resolvam' a condição, o envolvimento na operação seja totalmente ignorável.

No caso de um SQL dinâmico (independente à existência de Hibernate ou de quaisquer frameworks e afins), como seria o correto*?

*sendo, para fins de explicação, 'correto' o antônimo de 'gambiarra'

É estranho... pq 1 sera sempre = 1...

This message was edited 2 times. Last update was at 30/11/2009 17:22:06

luistiagos wrote:
É estranho... pq 1 sera sempre = 1...

Mas tu mesmo disseste:

A questão não é o resultado de 1 = 1, mas por que ele está sendo utilizado.

Sempre vi esse tipo de SQL em códigos que geravam instruções SQL dinâmicas. Suponha que tu tenhas um SELECT básico com vários filtros OPCIONAIS.

SELECT tabela.ID FROM tabela

Filtros: CampoA e CampoB. Um ou outro dos campos pode ser filtrado, mas nenhum é obrigatório, bem como não são dependentes entre si. Sem o uso do 1 = 1, preciso condicionar bem mais o código, ficando assim em exemplo (em JS pra simplificar):

Perceba, acima, que é necessário que os códigos subsequentes 'conheçam' a existência do WHERE na instrução.

Mas veja como ficaria simples se eu usasse o 1 = 1:

Concluindo: a expressão 1 = 1 existe só e somente só nestas especificidades de alguma necessidade de otimização (lê-se isso como 'subtração') de linhas de código.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

luistiagos wrote:

Yky Mattshawn wrote:

luistiagos wrote:quem não lembra da velha gambi para fazer muitas vezes sqls dinamicos?

where 1 = 1

Não consideraria isso uma gambiarra. É apenas um meio de tornar um código menos condicional. Agrega-se a isso o fato de '1 = 1' ser uma expressão que os SGDB's normalmente já são capazes de desconsiderar e, ainda que 'resolvam' a condição, o envolvimento na operação seja totalmente ignorável.

No caso de um SQL dinâmico (independente à existência de Hibernate ou de quaisquer frameworks e afins), como seria o correto*?

*sendo, para fins de explicação, 'correto' o antônimo de 'gambiarra'

É estranho... pq 1 sera sempre = 1...

Lógica booleana no SQL é estranha mesmo.

Um AND x = 1 AND x = 2 vai trazer valores onde x é 1 ou 2.

This message was edited 2 times. Last update was at 13/07/2009 16:26:10

Bruno Laturner wrote:

luistiagos wrote:

Yky Mattshawn wrote:

luistiagos wrote:quem não lembra da velha gambi para fazer muitas vezes sqls dinamicos?

where 1 = 1

Não consideraria isso uma gambiarra. É apenas um meio de tornar um código menos condicional. Agrega-se a isso o fato de '1 = 1' ser uma expressão que os SGDB's normalmente já são capazes de desconsiderar e, ainda que 'resolvam' a condição, o envolvimento na operação seja totalmente ignorável.

No caso de um SQL dinâmico (independente à existência de Hibernate ou de quaisquer frameworks e afins), como seria o correto*?

*sendo, para fins de explicação, 'correto' o antônimo de 'gambiarra'

É estranho... pq 1 sera sempre = 1...

Lógica booleana no SQL é estranha mesmo.

Um AND x = 1 AND x = 2 vai trazer valores onde x é 1 ou 2.

Mas qual o torpe SGDB que tens usado?

Ao menos no MySQL isso não funciona assim não...

Aliás, se testares alguma instrução do tipo que citaste com o 'EXPLAIN' no início, o MySQL será enfático ao declarar:

Impossible WHERE

P.S.: não considero a lógica booleana no SQL muito diferente da existente nas linguagens de programação. O SQL, às vezes, pode exigir mais atenção quanto à procedência de parêntesis, uma vez que toda a lógica se faz numa única linha (saldo SPs e FNCs), mas nada que torne essa lógica estranha.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Estranho, fiz no Oracle, tentei com uma consulta simples e realmente não deu certo.

Falei o que disse acima baseado numa consulta meio complicada. Agora tenho que achar ela de novo pra confirmar.

JavaEvangelist Membro desde: 21/11/2004 16:40:00 Mensagens: 424 Offline

Yky Mattshawn wrote:
Concluindo: a expressão 1 = 1 existe só e somente só nestas especificidades de alguma necessidade de otimização (lê-se isso como 'subtração') de linhas de código.

Ou, só existe qndo não se usa um Hibernate Criteria(ou qq outro tipo de abstração do SQL) =)

clone_zealot wrote:

Yky Mattshawn wrote:
Concluindo: a expressão 1 = 1 existe só e somente só nestas especificidades de alguma necessidade de otimização (lê-se isso como 'subtração') de linhas de código.

Ou, só existe qndo não se usa um Hibernate Criteria(ou qq outro tipo de abstração do SQL) =)

Somente na abstração da suposta comodidade de uma API gigante...

Veja o que podemos encontrar nos códigos do Hibernate:

Pelo visto, tem mais gente que usa esse 'auxílio'... até o pessoal abstrato, digo, o pessoal responsável pela abstração do Hibernate...

OBS: aquela comentário 'yuck' está mesmo no source do Hibernate.

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

clone_zealot wrote:

Yky Mattshawn wrote:
Concluindo: a expressão 1 = 1 existe só e somente só nestas especificidades de alguma necessidade de otimização (lê-se isso como 'subtração') de linhas de código.

Ou, só existe qndo não se usa um Hibernate Criteria(ou qq outro tipo de abstração do SQL) =)

Não existe não... vc não ve... ou vc sabe exatamente a query que o Criteria gera por traz?
ja vi o hql gerando muita query bizzara...

por isto não gosto muito do hql e nem Criteria...
depende muito do que vai fazer... se for algo simples dai blza... mas se for algo complexo ele pode gerar uma bizzarisse com a query do sql nativo...

Lembrei de mais um clássico. Davamos manutenção num sistema feito em C, e descobrimos que algumas variáveis de controle, imprescindíveis para o funcionamento do sistema, eram globais.

Isso por sí só já mereceria um lugar nessa lista... porém, uma delas tem destaque de honra:
A variável se chamava i.

Exatamente. Qualquer código que fizesse um "for (i = 0; i < x; i++)" estaria corrompendo um valor de controle importante, e global...

Obviamente, alguns programadores (que vieram depois do inteligente que declarou esse global), tentavam fazer declarações de i em escopos locais, recebiam um warning (de variável eclipsada) e então removiam a declaração...

switch(i){
  case 0: plano.setDescricao(visitas.get(i).getDataVisita() == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;						
  case 1: plano.setColuna1(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 2: plano.setColuna2(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 3: plano.setColuna3(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 4: plano.setColuna4(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break; 
  case 5: plano.setColuna5(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 6: plano.setColuna6(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 7: plano.setColuna7(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;					
  case 8: plano.setColuna8(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 9: plano.setColuna9(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 10: plano.setColuna10(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 11: plano.setColuna11(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
  case 12: plano.setColuna12(visitas.get(i).getDataVisita()  == null?"":DateUtil.format( visitas.get(i).getDataVisita(), "dd/MM/yyyy")); break;
}

Vamos salvá-lo da manutenção tenebrosa:

Ainda daria pra melhorar, mas já ajudou bastante.

This message was edited 1 time. Last update was at 06/08/2009 17:11:04

Eu faria assim ainda:

This message was edited 1 time. Last update was at 07/08/2009 11:23:58

Vou salvar a alma do incauto:

Nota do usuário: o método "addActionError" tem uma sobrecarga que recebe um ValidacaoException e já faz o trabalho repetitivo.

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