Quanto menos IFs e CASEs melhor, certo? Cada ramo de um IF ou de um CASE é uma excepção. E nós gostamos mais de regras do que de excepções. Aqui está mais uma técnica para o conseguir.

É muito fácil fazer asneira com os nomes dos objectos em SAP. Encontrei recentemente uma forma de minimizar esse problema: definir regras para fixar prefixos por pacote para determinados tipos de objecto.

Eu empacoto obsessivamente tudo o que mexe.

Quando se olha para o código fonte ABAP, a declaração dos métodos prefixa sempre os parâmetros de entrada com um ponto de exclamação. Isto sempre me intrigou. Finalmente sei o porquê.

Sabias que podes finalmente fazer alterações radicais num desenvolvimento sem medos porque há uma forma simples de desfazer todas essas alterações?

As excepções OO têm sempre de ter um pai. Têm sempre de herdar de alguém. E o ABAP dá 3 hipóteses, cada uma tratada de forma diferente pelo compilador.

As mensagens SAP são todas geridas de forma centralizada através da transacção SE91, mas podem aparecer a um programa nos mais diversos formatos.

Durante anos explicaram-me que se deve usar UP TO 1 ROWS quando a chave não é completa. A minha professora primária disse que devemos sempre perguntar porquê: porquê? Ninguém explica.

Imagina que queres mostrar um url num formulário. Colocas o url no texto do formulário e partes do princípio que tudo correrá bem. Porque, de facto, geralmente tudo corre bem. Só que às vezes…

Quando escreveres código deves estar sempre preocupado com quão fácil será mantê-lo. Isso é particularmente importante nas declarações de variáveis. E é tão simples de aplicar.

A transacção SE24 esconde parcialmente o código atrás de um GUI. Supostamente é para nosso benefício. Mas o que aparenta ser conveniente torna-se na realidade muito limitativo.

Demorei muitos anos mas finalmente livrei-me do raio dos prefixos.

O ABAP 7.4 trouxe uma série de novidades aplaudidas. Mas de todas, aquela em que menos se fala é o novo tipo de dados MESH. Vamos ver aqui quão injusto é tê-lo votado ao abandono.

Quando é preciso fazer alterações de fundo ao código o IDE do SAPGui não ajuda. O Eclipse ADT já é bem melhor mas mesmo assim há muitas alterações que essas ferramentas não conseguem automatizar. Nomeadamente alterações que têm de ser feitas centenas de vezes e que não se conseguem fazer com um simples find and replace. Nesses casos o mais normal é acabar por fazer tudo à mão.

Quando vais modificar registos na base de dados é comum fazeres primeiro um SELECT para ver como as coisas são e depois então fazeres UPDATE como as coisas serão.