É 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.
Não faças COMMIT dentro de user-exits. E garante também que rotinas que possas chamar a partir de user-exits não o fazem.
Se um desenvolvimento necessitar de mais do que uma tabela de parametrização, considera agrupar as tuas vistas de manutenção num “cluster”. Assim será mais intuitivo mantê-las. Isto fará ainda mais sentido se umas dependerem de outras uma vez que na definição do “cluster” estas relações podem ser explicitadas.
Exemplo: Como encavalitar tabelas
Tenta seleccionar sempre apenas os campos que vais realmente usar. Escolher todos é um desperdício de recursos. Excepção feita ao uso das FM *_SINGLE_READ que, embora leiam os campos todos, fazem cache dos dados, sendo por isso ainda assim mais rápidos de usar quando usados múltiplas vezes com a mesma chave. Se queres apenas verificar que um registo existe, selecciona apenas um campo, e se possível aquele que estás a usar como critério, evitando assim declarares uma variável extra. Exemplo: SELECT KUNNR INTO V_KUNNR FROM KNA1 WHERE KUNNR = V_KUNNR. https://abapinho.com/2010/11/select-todos-os-campos/
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: https://abapinho.com/2009/06/constantes/
Não caias na tentação de usar a T900 ou outras tabelas do género para este propósito. É certo que muita gente faz isso. Mas é feio, sujo e essas tabelas nem sequer têm uma chave adequada porque não foram pensadas para isso.
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;
Se precisas de adaptar o conteúdo de um ficheiro com valores (CURR) tem sempre em consideração a parametrização do utilizador (USR01-DSCFM). Se precisares de converter um alfa-numérico num número, usa o FM MOVE_CHAR_TO_NUM. Se precisares de converter um número num alfa-numérico, usa WRITE curr TO str [CURRENCY waers].
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. Isto é mais lento, mas como convenção pode ser mais intuitivo.