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!

Ao ler um ficheiro com valores numéricos para uma tabela interna ou vice-versa, o sucesso da conversão destes depende de o utilizador tem definido o ponto ou a vírgula como separador decimal. É costume ir então ler a configuração do utilizador e depois, adaptar os valores vindos do ficheiro com ponto ou vírgula conforme. Mas isto é lamentável e pouco elegante. Devia haver uma forma de não fazer a coisa depender do utilizador. E há.

Imagina que tens uma manada de classes relacionadas as quais partilham entre elas uma manada de constantes. Dizendo a mesma coisa de outra forma, gostavas que todas as classes da manada tivessem acesso de forma simples à manada de constantes. (Se estás baralhado, fica sabendo que a manada era só para baralhar) Continuando.

Cada vez uso mais RANGEs. Uso-os ao pequeno-almoço, ao almoço, ao jantar e fora das refeições. É como o molho de soja. Umas colheradas daquilo e fica logo tudo mais saboroso.

Partamos do princípio de que és uma pessoa com alguma dignidade e que por isso já não usas tabelas internas com HEADER LINE ;) Posto isto, imaginemos que declaras uma tabela interna:

A verdade nua e crua, custe o que custar, é que as estruturas estão fora de moda. Agora o que está em voga é FIELD-SYMBOLS. Quando fazes um LOOP a uma tabela interna, claro que também usas ASSIGNING FIELD-SYMBOL em vez de INTO estrutura, não é? Mas o que me lixava era o APPEND e o INSERT. Ainda não sabia como evitar usar uma estrutura para adicionar registos.

A SAP tem um livro chamado Official ABAP Programming Guidelines que descreve regras e boas práticas de como programar em ABAP. E lá diz assim (dizia em estrangeiro, eu traduzi): Pág. 42: Regra 3.1: Usa ABAP Objects sempre que possível para novos desenvolvimentos. Só podes criar blocos de processamento clássicos em casos excepcionais. Pág. 45: Num bloco de processamento clássico, deverás delegar imediatamente a execução para um método apropriado (ver Regra 6.

O dicionário diz o seguinte do verbete “estilo”: “conjunto de aspectos formais e recursos expressivos que caracterizam um texto”. Dá mais gosto ler textos com estilo do que textos sem estilo. Se o ABAP é uma linguagem, um programa em ABAP é um texto. Há programas que, no que toca ao estilo, parecem escritos com os pés; enquanto há outros que se poderia jurar que a pena que os escreveu deixou-se guiar pelas alvas mãos de uma qualquer donzela do século XVIII afligida por males de amor. Felizmente penso que não é possível escrever programas em ABAP tão pirosos quanto esta última frase. Aqui no Abapinho usa-se a etiqueta “estilo” para identificar artigos que falam sobre isso mesmo: estilo. Estes artigos tentam encontrar formas de melhorar o estilo dos programas ABAP. Esta é uma das etiquetas favoritas do Abapinho como podes ver aqui. E isto que estás a ler é mais um desses artigos. Adiante.

Se és daqueles que, em vez de usarem constantes, espetam com os valores directamente no código, então pára de ler isto e vai ali para o canto de castigo durante 1 hora que é para aprenderes a não ser mandrião. Quando voltares podes continuar a ler.