"
Etiqueta > estilo
Apoiado por

Boas prácticas
Usarás o comando TABLES só quando inevitável

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.

Boas prácticas
Usarás FIELD-SYMBOLs em vez de variáveis de estrutura

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.

Pacotes 2.0

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.

Ler o resto do artigo! »

Boas prácticas
Agruparás partes que estejam relacionadas

À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.

Boas prácticas
Evitarás mensagens dinâmicas

Quando precisares de enviar uma mensagem dinâmica por parâmetro, garante que ainda assim usas o comando MESSAGE de forma a que o “where-used” não lhe perca o rasto. Ao fazeres MESSAGE E001 INTO V_DUMMY, os detalhes da mensagem ficam disponível nas variáveis de sistema SY-MSGNO, SY-MSGTY, etc. Além disso, os textos das mensagens nunca devem ficar explicitamente definidos no programa mas sim definidos através da transacção SE91.

Evitar mensagens dinâmicas

Boas prácticas
Não implementarás código em user-exits

Todo o código que colocares em user-exits (BADIs, enhancements, SMOD, etc.) deverá ser encapsulado.

  • É comum incluir num user-exit múltiplas partes independentes. Cada uma destas partes deverá ser encapsulada no seu próprio método. Mesmo que seja constituída por apenas uma linha de código;
  • Isto deve ser aplicado tanto a implementações novas como a alterações a código existente;
  • A necessidade de alteração de código existente deverá ser vista sempre como uma oportunidade para reorganizar em métodos código clássico existente, uma vez que este terá necessariamente de ser testado de novo;
  • Se uma classe associada com um determinado user-exit ainda não existir, deverás criar-lhe uma;
  • O nome da classe deve estar claramente relacionado com o nome do user-exit: Ex: no user-exit ZXF01U01 usa a classe ZCL_ZXF01U01;

https://abapinho.com/2012/03/metodos-privados-em-badis/
https://abapinho.com/2009/03/melhorar-os-melhoramentos/

Boas prácticas
Não implementarás blocos de processamento clássico

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).

SELECT dentro de SELECT

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.

Ler o resto do artigo! »

Boas prácticas do Abapinho

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.

Nem todas agradarão a todos. E isso é bom. Digo eu egoisticamente. Pois tenho a esperança de que os desagradados se manifestem e as suas ideias e opiniões me ajudem a melhorá-las ou repensá-las.

Agradáveis ou não, espero que uma ou outra sejam, pelo menos, inspiradoras.

Aguardem-nas. Em breve começarão a aparecer.

O Abapinho saúda-vos.

O detective do ABAP

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.

Ler o resto do artigo! »

APPEND LINES OF classe->metodo() TO itbl

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:

Ler o resto do artigo! »

Usa sempre classes de mensagens nas classe de excepção

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.

Ler o resto do artigo! »

Funções Z misturadas com vistas de manutenção, não!

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.

Ler o resto do artigo! »

Gosto do LIKE

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.

Ler o resto do artigo! »

Escrever dinheiro sem preocupações decimais

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.

Ler o resto do artigo! »


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).