"
Etiqueta > estilo
Apoiado por

Boas prácticas
Encapsularás, encapsularás, encapsularás

Historicamente os programas ABAP tendem a ser muito loooongos. Todas as boas prácticas de programação ensinam que não há uma única vantagem nisso.
Se uma rotina, seja ela um programa, um método, uma função ou outra coisa, tiver mais do que 200-300 linhas, desconfia e considera seriamente modularizá-la em várias sub-rotinas.
Esta abordagem tem a vantagem adicional de potenciar a reutilização de código. Mas a maior vantagem é o encapsulamento, isolando variáveis no seu contexto local, em vez de as ter todas juntas, tendo como resultado código mais seguro e mais claro.
O livro Official ABAP Programming Guidelines aconselha istos no capítulo 2.2 KISS (páginsa 32-34).
http://help.sap.com/abapdocu_731/en/abenencapsulation_guidl.htm

Boas prácticas
Reutilizarás, não reescreverás

Se o mesmo pedaço de código estiver repetido mais do que uma vez, pergunta-te porquê e tenta evitá-lo, criando uma rotina reutilizável.
Se, num programa, existir mais do que um SELECT para a mesma tabela, tenta fundi-los num único. Por vezes a utilização inteligente de RANGES para unificar parâmetros pode evitar a necessidade de múltiplos SELECTs a uma mesma tabela.
Se o mesmo código for usado em dois programas diferentes tenta, ao invés, mover esse código para uma classe que possa ser partilhada pelos dois.

Mais RANGEs, menos SELECTs

Boas prácticas
Evitarás variáveis globais

Quanto mais variáveis globais existirem num programa, mais obscuro ele se tornará. Evita-as. Esta é uma das regras mais básicas da boa programação e deve ser seguida o mais possível. Mesmo se muitas variáveis tiverem de ser passadas entre rotinas. O esforço é um pouco maior, mas daí resultará código muito mais claro e seguro.
Excepções podem ser feitas no caso de relatórios muito simples que revolvam à volta de uma única tabela interna, tabela esta que poderá ser declarada globalmente sem comprometer a clareza do código.

Como perguntar se a linha existe sem parecer antiquado

Há muito tempo atrás dizias “porreiro pá”. Depois começaste a dizer “baril”. Depois era “fixe”. Hoje dizes “altamente”. É importante não te baralhares para não dares mau aspecto.

E como perguntas a uma tabela interna se a linha existe?

Ler o resto do artigo! »

Boas prácticas
Usarás TRANSPORTING NO FIELDS

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.

Pré-definir SELECT-OPTIONs

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.
Ler o resto do artigo! »

Cadeias de excepções

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:

Ler o resto do artigo! »

Ignorar excepções de um módulo de função

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.
Ler o resto do artigo! »

Concatenemos

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.

Ler o resto do artigo! »

Onde está o booleano?

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.

Ler o resto do artigo! »

LOOP at tbl ASSIGNING <linha> CASTING

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

Ler o resto do artigo! »

Boas prácticas
Não usarás CHECKs directamente em user-exits

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

Boas prácticas
Usarás LIKE LINE OF itbl

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.

Boas prácticas
Usarás uma tabela de constantes

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.

Boas prácticas
Criarás e adoptarás bibliotecas de ferramentas comuns

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;
  • Sempre que, ao desenvolveres código específico para algo, te pareça que este pode vir a ser reutilizado, considera torná-lo genérico e adiciona-o à biblioteca central.

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