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.

Há cada vez mais objectos em ABAP, cada vez menos medo deles e, vê só!, cada vez mais gente a escrevê-los e a usá-los. Ora, se começam a aparecer objectos por todo o lado, é normal e desejável que comecem a enfiá-los também dentro de tabelas internas. Também eu guardei há uns tempos um monte de objectos dentro de tabelas mas infelizmente na altura não sabia disto que vou ensinar aqui. Tinha-me dado jeito.

Mas afinal o que vou eu ensinar aqui?

Queres obter o texto de uma mensagem da qual só sabes o ID e o número e não sabes como? Aprende aqui: DATA texto TYPE string. MESSAGE ID '00' TYPE 'E' NUMBER '163' WITH '123' INTO texto. É só isto. Agora do lado de dentro da variável texto encontras o seguinte texto: “O mandante 123 não existe no sistema” Obrigado a Peteris B pela foto. O Abapinho saúda-vos.

Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.