Blindar o codigo ou deixa-lo aberto? O que faz mais sentido, criptografia propria ou entregar-se as solucoes prontas? Qual a decisao mais correta?Grande parte das peculiaridades das linguagens de programacao se deve ao fato de seu emprego ser propicio apenas em ocasioes absolutamente singulares. O resultado disso sao plataformas de programacao obscuras, merecedoras de horas de estudo e de pesquisa, alem de testes.Web sites com implementacoes XML, por exemplo, podem nao ter a instrucao de avisar ao navegador que ele deve se prepara para receber dados nessa forma. Quando isso acontece, as funcoes nao sao executadas de forma propicia, ate que os valores correspondentes sejam encontrados.Desenvolvedores sofrem especialmente com programas desenvolvidos pelo que e conhecido na industria de TI como Noob (novato, inexperiente). Estruturas antiquadas e ausencia de recursos que aumentem a robustez dos codigos estao entre os principais motivos de seu descontentamento.Mas existem outras questoes, todas de cunho tecnico, capazes de tirar definitivamente o sono dos desenvolvedores.Erro de programacao #1 Um codigo relapsoO caminho mais rapido em direcao a um programa falho consiste em relaxar na hora de desenvolver seu codigo. E comum isso se transformar em consequencias desastrosas, de acordo com a aplicacao, por parte de um usuario despreparado. Perguntas _ como sera que uma entrada 0 e capaz de achar seu caminho ate a operacao de divisao? Tera o texto submetido no tamanho correto? O formato das entradas foi verificado? A identidade do usuario e verificada na base de dados? _ acabam nao sendo feitas, levando a pequenos erros que podem comprometer um programa inteiro.Para piorar ainda mais, o design avancado de linguagens de programacao modernas, que deveriam corrigir esse tipo de contingencia, nao da conta de cumprir seu papel. Um exemplo disso e a ultima versao do Java, em que foi implementada a tentativa de facilitar a checagem por null-pointers com base em sintaxes abreviadas para a realizacao dos ensaios de apontadores. Basta adicionar um ponto de interrogacao a cada invocacao de metodo; automaticamente sera incluido um teste de null-pointers que ajuda a subsituir uma miriade de argumentos if-then desse tipo: public String getPostcode(Person person) { String ans= null; if (person != null) { Name nm= person.getName(); if (nm!= null) { ans= nm.getPostcode(); } } return ans }Por isso: public String getFirstName(Person person) { return person?.getName()?.getGivenName(); }Mesmo assim, no final das contas, esse tipo de correcao de codigos apenas evita que o codigo trave, sem garantir que seja um codigo util. Porque, em uma abordagem pragmatica, percebe-se que esses recursos nao erradicam o problema principal: a proliferacao de valores nulos, resultado de programacao relapsa.Erro de programacao #2 Ser refem de detalhesNa contramao do argumento anterior, codigos ultra detalhados podem transformar uma execucao breve em um processo que se arrasta parecendo nao ter fim. Nada contra verificar alguns null pointers, mas existem codigos que sao um exemplo de paranoia, dada sua rotina de verificacao obsessiva.Sobrecarregar codigos com rotinas de verificacao pode ser mal interpretado por determinados sites, o que ocasiona a negacao de servicos na rede. Tenho varios pacotes que, de tanto verificar se existem atualizacoes, rodam de maneira