Sempre usei * para comentar o código. Só usava " quando precisava de usar pseudo-comentários ou adicionar um pequeno comentário no final da linha. Mas há pouco tempo aprendi que faz muito mais sentido usar “.

O gestor de versões do ABAP é muito mau. Para além de todos os seus defeitos, ele não permite de forma fácil saber quem fez o quê e quando. O git, que é um gestor de versões a sério, permite obter essa informação facilmente através da sua ferramenta git-blame. Devido a isto, muitos ABAPers habituaram-se a acrescentar o seu nome e data a todas as linhas de código que acrescentam, que apagam e que alteram. Assim, à medida que um programa ABAP vai sendo mais modificado, mais ilegível se vai tornando e mais difícil é navegar entre versões para saber quem fez o quê.

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.

Não sei há quanto tempo é que isto está disponível mas só agora descobri que é muito fácil ver numa ALV o conteúdo de uma tabela interna durante debug.

Se tu que estás a ler isto achares que tudo o que está escrito no Abapinho é literalmente verdade, o que te vou dizer a seguir vai desiludir: quando disse mágico não quis dizer que era sobrenatural. É só uma forma mais abrilhantada de dizer que é surpreendente e inesperado. Tomei esta liberdade um bocado como quando dizes “estou morto de sede” e no entanto ainda estás vivo. Tendo clarificado isto, podemos continuar.

O SAP está replecto de recantos refundidos e rebuscados raramente reconhecidos que o Abapinho se regozija por revelar. O comando %pc é equivalente à opção de menu Sistema/Lista/Gravar/File local:

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.

Em tempos falámos na SAAB e nas vantagens de a utilizar para melhor conseguir analisar e descobrir problemas no nosso código. Nesse artigo não expliquei uma coisa que é realmente importante: variantes de activação.

Já todos usámos enhancements implícitos para adicionar código ao início ou final de funções, forms ou métodos standard. Mas é menos conhecido o facto de que também podemos adicionar campos a estruturas de dados, estejam elas declaradas como TYPES ou ou directamente como DATA.

No outro dia estava a aprender sobre ST (Simple Transformations) e lembrei-me que, ainda que tenha sido desenvolvida para transformar dados, é uma forma práctica de guardar dados XML. Temos o seguinte XML: <cocktails> <cocktail id="gt" nome="Gin Tonic"/> <cocktail id="ws" nome="Whiskey Sour"/> <cocktail id="cl" nome="Campari Laranja"/> </cocktails>

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