Como é que se há-de traduzir dummy? Fica manequim. Comecei a trabalhar recentemente num cliente novo e reparei que fazem aqui uma coisa que me agradou. Quando precisam de invocar por RFC módulos de função em outros sistemas SAP, criam localmente um módulo de função com o mesmo nome mas sem código, apenas com um comentário explicando que é uma função remota noutro sistema. A virtude disto é que assim pode usar-se a ferramenta where-used para descobrir todos os sítios onde é invocada.

Antes do 7.40 ter modernizado o ABAP, um lookup a uma tabela obrigava a declarar uma variável auxiliar e a pelo menos 4 linhas de código.

Durante muitos anos, quando entrava em discussões sobre ABAP OO ser melhor do que FORMs, INCLUDEs e CALL FUNCTIONs, o mais comum é a pessoa do lado de lá continuar convencida de que OO é bom nas outras linguagens mas não traz vantagens para o ABAP. Logo a começar pelo atroz código standard SAP que parece ter sido escrito para provar que é possível fazer algo que viola todas as boas prácticas de programação e mesmo assim funciona.

Não, o ABAP nunca vai ter o operador NOT.

O Abapinho não tem falado muito sobre o 7.40 porque as suas novidades têm já sido amplamente descritas em vários sites. Tentamos não inventar a roda.

Mas há pequenas pérolas úteis que ainda são pouco conhecidas. Esta é sobre uma delas.

Hoje debruçamo-nos sobre como tentar optimizar o código para transformar um SELECT num RANGE.

Há alguns anos atrás mostrei como se podia converter uma MESSAGE normal numa excepção tipificada. Entretanto o ABAP evoluiu um bocadinho e agora, na versão 7.40, aquela solução complexa já não é necessária.

Quem lê o Abapinho sabe que eu defendo o uso e abuso do ABAP Package Concept. Hoje em dia a primeira coisa que eu faço quando começo um desenvolvimento novo é criar-lhe um pacote encapsulado que guardará todos os seus objectos que, nos casos mais complexos, será um pacote “Main” ainda subdividido em vários sub-pacotes.

Fica aqui a minha modesta proposta para criar uma árvore de pacotes Z que ajude a organizar aquilo que é normalmente uma confusão danada.

O sistema do cliente onde trabalho actualmente foi finalmente actualizado para o 7.50 e, depois de tantos anos preso ao ABAP convencional, posso desfrutar as maravilhas introduzidas no 7.40.

São às dúzias essas maravilhas, e não vou começar aqui a fazer artigos sobre cada uma porque já existem artigos espalhados pela net sobre quase todas elas o Abapinho faz sempre o possível por ensinar algo novo ou, pelo menos, pouco conhecido.

Mas há uma singela funcionalidade que, não sendo nada de extraordinário, me agrada: já não é preciso fazer IS INITIAL no comando IF quando a condição é um método que retorna um booleano.

É frequente ao programar começar a sentir um cheiro desagradável. Normalmente não consigo logo identificar o que é. Sinto apenas uma leve mas incómoda fragrância. À medida que vou cheirando com mais propósito vou conseguindo perceber de onde vem. Mas mesmo nessa altura, muitas vezes ainda não me é perfeitamente claro porque é que aquele cheiro dali vem.

Desde 1998 que oiço colegas ABAPers dizerem que não vale a pena meter determinado código numa função ou método porque não lhes parece que este vá tornar a ser reutilizado. E lá vão continuando na SE38 a fazer os seus reports cheios de includes.

A ideia de que a principal razão para encapsular código é poder reutilizá-lo é um dos maiores mal entendidos da história do nosso planeta.

No mundo do SAP, o código ABAP onde cai é onde fica.

Num dia o Manel faz uma coisa mal porque está com pressa ou não sabe fazer melhor. Um ano depois pedem ao António para fazer uma pequena alteração. O António vê a asneira do Manel mas não a melhora porque, por alguma razão, no mundo do SAP, alterar código que está a funcionar, por muito mau que seja, é tabu. Em vez disso, acrescenta o seu código ao já existente de forma geralmente acrítica.

Esta atitude, quando adoptada por todos, contribui para uma inevitável erosão do código de um sistema que, após alguns anos, se tornará ingerível.

No meu entender, isso está errado e vai contra os interesses do cliente. Aliás, mesmo se o cliente não quiser que se mexa no código antigo… eu mexo. Quem é ele para me dizer como é que se programa?

Na escola aprende-se que o código deve ter sempre comentários. Depois, na vida real, descobrimos que nem toda a gente prestou atenção na escola.

Sempre tive o cuidado de comentar os vários passos do meu código, especialmente as partes mais obscuras ou que não são auto-explicativas.

Mas depois de ler o livro Clean Code do Uncle Bob, a minha opinião mudou. Hoje acredito que quanto menos comentários melhor. E no entanto não acho que esta mudança seja contraditória.

O João estuda Engenharia Informática na Universidade onde aprende Java, polimorfismo, encapsulamento e uma série de outras técnicas e boas prácticas. Quando termina o curso é contratado por uma empresa para trabalhar em SAP. No curso de introdução ao ABAP que a empresa lhe oferece, a primeira coisa que ensinam é como fazer o programa ZJOAO. Explicam assim:

_“Vais à SE38, crias o programa ZJOAO e crias logo os includes ZJOAO_TOP, ZJOAO_FRM e ZJOAO_SEL. Depois metes as variáveis todas no _TOP, o ecrã de selecção no _SEL e todos os FORMs no FRM. A partir daqui é só ires programando. Primeiro escreves START-OF-SELECTION e a seguir fazes todos os SELECTs e depois escreves END-OF-SELECTION e mostras tudo numa ALV. É simples, vês? Bem-vindo ao ABAP."

Este artigo é da autoria de José Vília.

A ovelha Dolly está no ABAP e eu não sabia.

Depois de criar uma instância de uma classe, gostava de partilhá-la com outro programa totalmente independente para que este outro programa posso usá-la como se a tivesse instanciado.

Como se de uma fábrica de ovelhas Dollies se tratasse, o ABAP pode utilizar serialização para resolver o problema.