Por outro lado, algumas formas de codificar ajudam a simplificar o código e a torná-lo mais legível. Nos laços, por exemplo, é comum ter que testar se uma referência é nula:
if(a!=null) {
for(int i=0; i<a.length; i++) {
System.out.println(a[i]);
}
}
Basta tirar o if e incluir a condição no for:
for(int i=0; a!=null && i<a.length; i++) {
System.out.println(a[i]);
}
Se estou usando descendentes de List, costumo criar uma subclasse (esse truque aprendi com um programador de C#) e nela coloco uma instância estática vazia (e aproveito para criar um array vazio também):
public class PessoaList extends ArrayList<Pessoa> {
public static final PessoaList EMPTY_LIST=
Collections.unmodifiableList(new PessoaList(0));
public static final Pessoa[] EMPTY_ARRAY=new Pessoa[0];
}
Com isso, cada método que retornar uma lista vazia de Pessoa pode usar uma dessas referências. Não economiza muita memória, mas economiza ifs e tempo do coletor de lixo.
NULLs são um saco.
ResponderExcluirParece que PL/SQL é ainda pior (não conheço muito). Comparações com NULL só funcionam com o operador "is". Outros operadores, só retornam bobagem (acho que retornam sempre false)
if 'a' <> null then
dbms_output.put_line('diferente');
else
dbms_output.put_line('igual');
end if;
Sai 'igual' :-(
E considerando que o Oracle considera null e '' como a mesma coisa, 'a' <> '' retorna false!
Coisa de louco!
De fato, PL/SQL adiciona mais complicações ao NULL. Por isso algumas pessoas criam um registro em cada tabela para ser o nulo e depois só precisam usar inner join. Também se economizam uns bits, porque as colunas com NULL precisam de um bit para indicar se o valor é nulo ou não.
ResponderExcluir