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.

A lei do menor esforço, esse grande axioma da Humanidade, tem, no mundo da programação, a particularidade de, em muitos casos, acabar por ser simplesmente a lei do esforço adiado. Porque é muito provável que algo que tenha sido desenvolvido de acordo com esta lei venha mais tarde a precisar de um grande esforço extra. Seja dos utilizadores que vão utilizar esse algo ou dos programadores que mais tarde terão de o manter. Atire a primeira pedra aquele que não se deixou guiar por esta lei ao desenvolver este ou aquele programas. Eu não atiro.

Prólogo Quando digo que gosto de usar diagramas de classes UML para documentar o meu código as pessoas acham que sou maluco. Introdução O UML ganhou má fama porque as pessoas pensam que primeiro se faz o diagrama de classes todo em UML e só depois o programa. Mas isso era em 1996, quando se achava que a primeira coisa a fazer era o desenho técnico todo, mesmo que na práctica ninguém nunca o fizesse. Hoje em dia felizmente já não temos vergonha de dizer que o próprio acto de programar é já em si uma forma de desenhar.

Quem lê o Abapinho sabe quanto gosto de classes de excepções. No entanto, este não é o único mecanismo que o ABAP disponibiliza para controlo de erros. Há outro, chamado ASSERT, que devia ser mais usado, e que hoje trago à baila.

Nos dias que correm se não estás a usar objectos és totó. Se usas objectos, espero que estejas a seguir a boa práctica de usar classes de excepções. E se usas classes de excepção é bom que entendas a melhor forma de as usar, particularmente as vantagens de as encadear. Com tudo isto esclarecido, chegamos ao que nos traz aqui hoje. No artigo sobre cadeias de excepções mostrei como, para obter o texto da excepção mais profunda, a que foi inicialmente espoletada, se pode fazer um DO WHILE:

Tenho usado cada vez mais referências em ABAP. Primeiro usava REF TO só para classes mas vou percebendo cada vez mais as vantagens de as usar também para estruturas de dados. Mas, tal como acontece em C++, há que ter cuidado quando se lida con referências para dados pois facilmente a coisa pode dar para o torto. Neste artigo tento mostrar como usar e como não usar o REF TO data. Comecemos por ver um exemplo de como não usar:

Todos os objectos criados em SAP têm de estar associados a um pacote. Até recentemente, quando eu queria fazer um teste rápido criava o objecto no pacote $TMP. Tinha assim a garantia de este nunca viria a ser transportado. Mas por vezes há necessidade de criar coisas no sistema de desenvolvimento que não pretendemos nunca vir a transportar mas que queremos que lá existam eternamente. Como o ZSAPLINK e o abapGit, por exemplo. Mas se as associarmos todas as pacote $TMP fica uma valente confusão.

Tenho usado cada vez mais referências em ABAP. Primeiro usava REF TO só para classes mas agora vou percebendo as vantagens de as usar também para estruturas de dados. Recentemente descobri um comportamento muito lamentável do seguinte comando: INSERT wa INTO itbl REFERENCE INTO ref. Mas antes de me queixar sobre isso, dou um bocado de contexto.

Se, ao construir uma ponte, um engenheiro civil fizer mal as contas a ponte cai. Mas não é só a ponte que cai. Esse engenheiro civil provavelmente também cai. Ou pelo menos desequilibra-se. Porque quando fez o projecto da ponte assinou-o, assumindo responsabilidade pelo que fez. Nós os programadores ABAP não temos esses problemas.

Todos já ordenamos tabelas internas e utilizamos a instrução AT NEW. Mas a partir da 7.40, podemos utilizar GROUP BY no LOOP. É fantástico a capacidade de agrupamento em que os valores do registo processado no loop podem ser comparados, recorrendo a expressões e até métodos. O agrupamento é realizado num primeiro LOOP e pode ser processado a seguir. Experimentem o seguinte código e, tal como eu, ficarão impressionados com o caminho que o ABAP está a seguir.

Quando aprendemos ABAP ensinam-nos uma série de regras sobre como dar nomes a variáveis. Ainda que nem todos acabem por dar nomes iguais, ainda assim partilham-se algumas ideias rígidas: As variáveis locais começam por L: L_BUKRS; As variáveis globais começam por G: G_MODE; As tabelas internas têm de ter lá um T_: LT_MARA; As estruturas têm de ter lá um S_: LS_MARA; As referências para objectos começam por R_: R_CUSTOMER; Os parâmetros input devem começar por I, os output por O, os changing por C e os returning por R. E a mais estúpida de todas, os field-symbols devem começar por FS_: <FS_MARA>. No início do século XXI isto até fazia sentido (excepto a dos field-symbols que já na altura era tão estúpida como escrever a palavra “lápis” em todos os lápis que tivermos). Hoje quase já não. Passo a explicar.

Se queres serializar um conjunto de strings que tens guardadas numa tabela interna tens duas formas de o fazer. Uma ranhosa e outra cheia de estilo.