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.

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.

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.

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?

Há módulos de função standard que lançam mensagens e não deviam. Não deviam porque depois queremos usá-las em programas não interactivos e, em vez de devolverem o erro, atiram com uma mensagem para o ecrã que dá cabo do processo.

Mas, provavelmente por ter tomado consciência deste problema, a SAP disponibilizou uma forma elegante (mas muito mal documentada) de resolver o problema.

A SAP não sabe fazer as coisas bem à primeira. As WebDynpros são um bom exemplo disso. Aquilo nem sequer permite pesquisar texto. É triste.

Felizmente o Sérgio Fraga descobriu uma forma, ainda que rebuscada:

Tenho 6 anos! (Obrigado Caleb Prichard pela foto)

É comum encontrar as estruturas de dados das ALVs declaradas explicitamente no código. Quando isto é feito, o catálogo de campos tem de ser criado manualmente. Se em vez disso se usar uma estrutura pré-definida (do DDIC ou como TYPE), o catálogo de campos pode ser criado automaticamente. Esta abordagem é sempre melhor resultando em menos código, mesmo que o catálogo de campos tenha de ser reajustado aqui e ali. https://abapinho.

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.

Imagina que tens um programa a executar um ciclo infinito ou, pelo menos, um ciclo com 70x7 iterações. Nunca mais acaba e tu queres saber o que lá se passa.

No passado tinhas de ir à SM50, seleccionar o processo e escolher no menu “Administração | Programa | Depuração”.

Mas agora há uma forma muito mais simples.

Por muitas voltas que eles dêem no ABAP, acaba tudo por ir dar à SE38. Até os métodos das classes ABAP são guardados em includes.

Às vezes quando há um dump diz que o problema está, por exemplo, aqui: CL_MESSAGE_HELPER=============CM001.

Liberaste uma ordem de transporte porque achavas que estava tudo pronto. Mas afinal ainda faltava fazer mais uma pequena modificação. E agora vais ter de criar uma nova ordem e transportar as duas. Que grande chatice.

Calma.

Já conheces a app EGSAP_TECH? É um repositório de informação SAP.

Aqui fica uma descrição delan nas palavas dos próprios criadores:

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: