Quando vais modificar registos na base de dados é comum fazeres primeiro um SELECT para ver como as coisas são e depois então fazeres UPDATE como as coisas serão.
Quando chego a um projecto novo atribuem-me uma chave de desenvolvimento para cada sistema de desenvolvimento associado. Normalmente esta é-me enviada por e-mail. Normalmente perco-lhes o rasto.
Imagina que és um macaco pendurado no galho de uma árvore. Queres saltar para outro galho mas ele está tão longe que não o consegues ver. Se saltares arriscas-te a cair ao chão. É mau.
O ABAP evolui (embora durante muitos anos não parecesse). E à medida que evolui vai deixando para trás alguns comandos ou formas de fazer as coisas porque disponibiliza outras melhores.
Para além de aprender a usar as novidades é também importante aprender a deixar de usar o que vai ficando obsoleto.
A legibilidade é muito importante em todo o texto escrito. Talvez com a excepção da poesia concreta.
Na sequência do post anterior, aqui fica um par de regras que minimizam o esforço que alguém tem de fazer para compreender expressões booleanas.
Porque haveria de ser difícil lê-las? Só tornaria mais difícil a vida de quem vier a precisar de a entender.
Lá porque uma condição IF é complexa não é por isso que tem de ser complicada.
Quantas vezes na tua vida de consultor tiveste de lidar com dumps que aconteceram em consequência de um programa tentar inserir duas linhas com a mesma chave numa tabela interna definida com UNIQUE KEY?
Chega.
Em 2012 lamentei que a LISTBOX fosse tão pouco usada. Ensinei a usá-la com elementos de dado standard, que a populam automaticamente. Hoje vou-te ensinar como a podes popular tu próprio se quiseres listar opções que não venham de um elemento de dados.
Quando tens de enviar o mesmo email para mais do que um endereço, o mais comum é guardar a lista de endereços numa tabela qualquer e depois adicionar todos os endereços como recipientes.
Mas aprendi recentemente uma forma muito mais bonita para conseguir o mesmo resultado.