Porquê sempre MODIFY?

É hábito em ABAP usar o MODIFY em vez de INSERT e UPDATE. Costumas fazê-lo? Explica-me porquê. É preguiça? É medo? É na base do “já agora”? Ou é mais na base do “caga nisso”?
É hábito em ABAP usar o MODIFY em vez de INSERT e UPDATE. Costumas fazê-lo? Explica-me porquê. É preguiça? É medo? É na base do “já agora”? Ou é mais na base do “caga nisso”?
O meu projecto tem constantes espalhadas por todo o lado, com nomes confusos ou errados. Uma salgalhada. Encontrei uma forma de reorganizar e rearrumar as constantes para que o código novo possa usar constantes bonitas sem espatifar o código antigo que pode continuar a usar as confusas.
Não há coisa pior do que ver gente a abusar das variáveis. São tão delicadas e no entanto tão mal tratadas, coitadas. Ora aqui está uma forma de lhes mostrar algum amor.
Toda a gente usa linhas em branco para melhor organizar o código. Mas onde usar e quantas usar? Falemos disso.
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.
Imagina que és um macaco pendurado no galho de uma árvore. Queres saltar para outro galho mas ele está tão longe que não o consegues ver. Se saltares arriscas-te a cair ao chão. É mau.
Um dos principais pontos fracos de um programa são os dados introduzidos pelos utilizadores.
Os programadores ABAP são muito poupadinhos. Quando lhes aparece um LOOP à frente gostam de o aproveitar para fazer tudo e mais alguma coisa. Mesmo que esse LOOP fique com centenas ou milhares de linhas.
O ABAP evolui (embora durante muitos anos não parecesse). E à medida que evolui vai deixando para trás alguns comandos ou formas de fazer as coisas porque disponibiliza outras melhores.
Para além de aprender a usar as novidades é também importante aprender a deixar de usar o que vai ficando obsoleto.
Quando os programas estão mal feitos por terem código duplicado, se os reescrevemos ficam mais curtos. Mas se, pelo contrário, estiverem mal feitos por não estarem devidamente estruturados em várias classes com vários métodos, podem ficar bem mais longos se os reescrervemos de acordo com as boas prácticas.
Infelizmente isto não acontece no código Z dos clientes onde tenho trabalhado. Tanto os IFs como os LOOPs tendem a ser tão grandes que ninguém percebe nada do que lá está. Ainda no outro dia vi um LOOP
com mais de 1500 linhas.
Demasiadas regressões acontecem porque alguém se esquece de fazer CLEAR ou de não fazer CLEAR a uma variável.
Porque haveria de ser difícil lê-las? Só tornaria mais difícil a vida de quem vier a precisar de a entender.
Lá porque uma condição IF é complexa não é por isso que tem de ser complicada.
Vamos por partes.
Imagina um cenário em que tens uma tabela de parametrização com vários níveis de detalhe que podem ou não estar definidos:
BUKRS (empresa)
WERKS (plant)
LGORT (depósito)
Quando um dos campos está vazio, é um wildcard, ou seja, é válido para todos os valores.