Muitas vezes fazes READ TABLE itbl ou LOOP AT itbl apenas para verificar se um registo existe (CHECK SY-SUBRC = 0). Ora para isso, os dados do registo não são realmente necessários. Nestes casos usa sempre TRANSPORTING NO FIELDS. Assim evitas ter de declarar uma estrutura destino e o programa fica mais rápido porque não tem de perder tempo a copiar dados.

O Abapinho recebeu uma carta. Sr Abapinho, Todos sabemos como colocar valores por defeito em select options usando o comando DEFAULT. O que nem toda a gente sabe é que podemos também definir por defeito a opção e o sinal e mesmo o botão para restingir o select options.

Hoje vou ensinar-te a encadear excepções. É uma solução muito práctica para um problema complicado mas pouco óbvio. Começo por descrever o problema. Imagina que estás na aplicação BANANA. É uma aplicação bastante complexa. Tem, aliás, três módulos. São eles BANANA1, BANANA2 e BANANA3. Cada um tem a sua classe de excepção ZCX_BANANA1, ZCX_BANANA2 e ZCX_BANANA3. E como a aplicação até está bem desenhada, todas as classes de excepção herdam da mesma ZCX_BANANA. Agora imagina o seguinte cenário. Estás no módulo BANANA1 a fazer não sei o quê. E lá tens de chamar uma classe do módulo MORANGO Ora essa classe lança, claro, excepções, do tipo ZCX_MORANGO. Este é o contexto. Tens várias hipóteses:

Quando chamas um módulo de função que devolve excepções normalmente dás-lhes números sequenciais tipo isto: CALL FUNCTION 'VAI_ALI_MAS_VOLTA' EXPORTING ali = 'Barreiro' EXCEPTIONS NOT_FOUND = 1 GOT_LOST = 2 OTHERS = 3. Mas se a seguir não tiveres o cuidado de ter um IF ou um CASE a olharem para o SY-SUBRC o Code Inspector pode devolve-te um erro caso esteja configurado para tal.

Temos duas variáveis: DATA palavra1 TYPE string. DATA palavra2 TYPE string. DATA: frase TYPE string. palavra1 = ‘isto’. palavra2 = ‘aquilo’. E queremos concatená-las metendo entre elas a palavra ‘mais’ e, claro, separando-as por espaços.

Não está. Mas eles - os senhores que fazem e refazem o ABAP propriamente dito - vão tentando remediar a situação. Olha por exemplo esta nova funcionalidade.

Sabias que podes fazer LOOP de uma tabela interna com uma estrutura A para dentro de uma estrutura do tipo B?

É comum encontrar o comando CHECK em user-exits. A trágica consequência disto é que, se o CHECK falha, nenhum do código que se segue a esse CHECK será alcançado. Como é comum (ainda que má prática) que num user-exit sejam tratados vários assuntos diferentes, um CHECK relacionado com um assunto pode inibir o acesso aos assuntos seguintes. Uma forma simples de evitar este risco é, como sempre aconselho, encapsular o código em rotinas.

Ao declarar uma estrutura que vai receber dados de uma tabela interna, em vez de a declarares directamente com o seu tipo, usa LIKE LINE OF. Assim, não só ficará claro que estão relacionadas como, se mudares o tipo da tabela interna, não terás de te preocupar em mudar também o tipo da estrutura.

Sempre que achares que um valor que estás a usar num programa pode mudar e não o puderes tornar um parâmetro de entrada ou do ecrã de seleccção, guarda-o numa tabela de constantes (ex: ZCONSTS). Esta tabela nunca deverá ser usada directamente. Em vez disso, cria uma classe ZCL_CONSTS que aceda a ela e usa sempre esta classe para obter as tuas constantes. Como é mostrado neste artigo: Não caias na tentação de usar a T900 ou outras tabelas do género para este propósito.

Código que seja usado comummente deve estar disponível centralmente, se possível guardado em pacotes bem identificados (ex: ZFERRAMENTAS) para que seja facilmente encontrados e transportados. Há muito código já disponível na Internet que permite executar várias funções comummente necessárias (ex: ABAP2XLSX). Adopta-o; Para as tuas tarefas mais comuns, desenvolve ferramentas que possas reutilizar, juntando-as à biblioteca central; Divulga a biblioteca entre os colegas do teu projecto para evitar que venham a perder tempo a criar código duplicado;

Uma das únicas situações onde é inevitável é com SELECT-OPTIONS. Em todos os outros casos, declara explicitamente uma variável local com uma estrutura equivalente. Basicamente o comando TABLES cria variáveis globais obscuras que aumentam a ambiguidade do código. E variáveis globais devem ser evitadas na maior parte dos casos.

READ TABLE itbl ASSIGNING é sempre mais rápido que READ TABLE itbl INTO wa. Além disso, quando precisares de alterar dados em registos de uma tabela interna, assim não precisas de usar o comando MODIFY nem da variável auxiliar que às vezes usas para guardar o SY-TABIX. A única situação em que uma variável de estrutura é aconselhada é quando queres adicionar linhas novas a uma tabela interna. Algumas pessoas defendem que as variáveis de estrutura devem ser usadas sempre que não se quiser alterar os dados da tabela interna.

O repositório do R/3 é uma coisa maravilhosa. Um vasto armazém de elementos de dados, estruturas, tabelas e muito mais, prontamente disponíveis a todos. Como programadores, é fácil e conveniente escolher estes objectos e puxa-los para os nossos programas à medida das necessidades sem que a preciosa linha de pensamento seja interrompida. Mas nem tudo é sol e flores. Se não tiveres cuidado com os cogumelos que apanhas podes dar por ti com um envenenado entre mãos.

Às vezes encontras um IMPORT no código mas não fazes ideia onde está o EXPORT correspondente. Quando for necessário comunicar entre programas distintos, isto deverá ser feito através de um par de métodos de uma mesma classe. Assim, quando nos cruzarmos com um, conseguimos facilmente saber qual é o outro. Para implementar esta comunicação, evita utilizar EXPORT/IMPORT sempre que possível. Ao invés, usa um atributo estático da classe.