Official ABAP Programming Guidelines (page 34): [Quando um bloco de processamento clássico for necessário], deves imediatamente delegar a execução para um método apropriado (ver a regra 6.37, Não implementes código dentro de Módulos de Função nem dentro de Subrotinas, e a regra 6.44, Não implementes código dentro de Módulos de Diálogo nem de Blocos de Evento).

Provavelmente por razões históricas, os programadores ABAP não exploram as possibilidades do SQL. Muitos há que em vez de usarem INNER JOINs, ainda julgam que é mais rápido fazer vários SELECTs para tabelas internas e depois trabalhar os dados em ABAP. Mas a verdade é que, mesmo que se haja excepções, a regra é: quanto menos acessos à base de dados, melhor a performance. E faz sentido porque, afinal, porque foram escritas explicitamente para isso, as bases de dados relacionais são muito mais peritas em processar dados relacionais do que um programa ABAP.

Mas claro que há coisas que, pela sua complexidade, não podem ser feitas com um simples INNER JOIN. Ainda assim, algumas dessas coisas podem ser feitas num único SELECT.

Ao longo dos últimos tempos compilei um conjunto de boas prácticas que fui adoptando para mim próprio. Resolvi partilhá-las aqui, criando para isso uma nova categoria (que aparecerá em breve no menu à esquerda) sob a qual serão agrupadas. A ideia original era fazer um PDF mas, como elas estão em constante revisão e ampliação, tornava-se pouco práctico. Como tal, serão publicadas uma a uma.

O objectivo é que estas possam ser vistas no seu conjunto como uma referência acessível de fácil consulta. Vocês não sei mas eu, pelo menos, consultá-las-ei.

Em SAP, quando um desenvolvimento está concluído, chega finalmente o momento de o enviar para outros sistemas onde pode ser devidamente testado e por fim executado pelos utilizadores. Mas antes disso, é crucial verificar se não existem lapsos, erros e afins que possam levar ao aparecimento de alguns comportamentos imprevisíveis por parte dos nossos programas. Existe uma ferramenta muito útil que permite filtrar alguns desses erros e lacunas. Chama-se ABAP Code Inspector.

O ABAP anda cada vez mais esperto. Ainda sou do tempo em que não se fazia nada dele. E agora, lentamente, com mais de um quinto de século de atraso, lá vai tentado imitar o C e o Java e ficando mais flexível.

Eu ia fazer algo deste tipo:

As classes de excepção permitem declarar múltiplos textos que descrevem os diferentes erros possíveis que elas podem representar.

Há no entanto uma opção para a associar a uma classe de mensagens (SE91). Isto permite que, em vez de os textos serem definidos directamente ali na classe de excepção, sejam antes definidos como clássicas mensagens da SE91. E tem vantagens.

A dica de hoje não é uma dica. É um conselho.

Criada uma tabela, depois crias as suas vistas de manutenção. As vistas de manutenção vivem dentro de um grupo de funções. Grupo de funções esse que te é pedido aquando da criação delas. Porque afinal aquilo não passa de um conjunto de código gerado, sendo que a maior parte são ainda assim includes standard. Montes deles.

Apresento-te o problema: há quem crie funções Z suas e as coloque em grupos de função que contêm vistas de manutenção. É verdade. Há quem o faça.

Nos maus velhos tempos em que o ABAP era ainda mais antiquado do que é hoje, as declarações de variáveis eram quase todas feitas com LIKE e referenciadas a campos de tabelas:

DATA: V_KUNNR LIKE KNA1-KUNNR.

Há quem leia a TCURX para descobrir o número de casas decimais de uma MOEDA quando precisa de escrever um campo endinheirado para uma variável ALFANUMERICA.

És assim? Não sejas.

Finalmente, com o SAP NetWeaver 7.0 Enhancement Package 2 o ABAP começa a parecer-se com uma linguagem de programação normal.

Até já dá para encadear expressões, vê lá tu!