Manias de Código

Todo programador tem as suas “manias”: SEU jeito de fazer um READ TABLE, o SEU jeito de escrever um SELECT… Muitos desses costumes dependem do seu aprendizado (herdados do seu mentor ABAPer), outros são desenvolvidos com o tempo, conforme você vai descobrindo o que funciona e o que não fuciona para suas necessidades.

O fato é um só: todo programador tem as suas “manias”. Aqui eu compartilho as minhas e espero que você também compartilhe as suas.

Para começar, eu confesso que demorou um bom tempo para que eu admirasse as diferentes formas de estruturar um código.  No começo eu sempre pensava que o MEU jeito era, obviamente, o jeito mais claro para que EU entendesse o meu código (o que faz sentido), mas também achava que o MEU jeito era o melhor para que os OUTROS entendessem meus códigos (o que demonstra uma prepotência desgraçada). Mas um dia a gente cresce e larga a mão de besteira, sabe como é .

Para não virar zona, vou organizar por tópicos.

SELECTs

Eu tenho uma forma bem particular de organizar meus SELECTs, tanto que só de bater o olho eu já sei se fui eu ou não que fiz aquilo. Basicamente eu sigo um padrão bem idiota de alinhamento do código, que não faz sentido algum. Vamos fazer um SELECT com FOR ALL ENTRIES:

SELECT campo1
       campo2
       campo3
  FROM tabela_standard
  INTO TABLE tabela_interna
   FOR ALL ENTRIES IN fae_table
 WHERE campo1 = 'bla'
   AND campo2 = 'bla'.

•  Eu nunca coloco mais de um campo de seleção na mesma linha. Nunca.
• O alinhamento é bizarro: eu alinho pelas primeiras palavras reservadas de cada pedaço do comando: SELECT, FROM, INTO, FOR, WHERE e AND. Se tiver mais de uma não importa, alinho só  pela primeira (como o INTO de INTO TABLE).
• Todos os operadores lógicos (AND/OR) vão abaixo do WHERE, abaixo um dos outros.
• Agora a melhor parte: se tiver um INNER JOIN eu não ligo que ele quebre a formatação, mas o resto precisa ficar alinhado como eu já expliquei. Sabe-se lá o porquê.

Dá para dizer também que eu nunca uso EQ, LT, GT e etcs… mas isso vale para todo o código, não só par ao SELECT.

READ TABLE

O Mauro gosta muito desta mania. Um chefe que eu tive e que me ensinou muito sobre SAP e ABAP me passou essa mania como um legado e eu sigo isso até hoje. Pensando bem, acho que ele nem sabe que eu faço isso por causa dele, então fica como se fosse uma cópia.

Esse daqui você vai achar estranho, certeza.

Meu READ TABLE é igual um hamburguer. Sério.

READ TABLE tabela INTO workarea WITH KEY
  campo1 = 'bla'
  campo2 = 'bla'
BINARY SEARCH.

Não entendeu? Se liga:

PAO COM GERGELIM
  dois hamburgueres
  alface
  queijo
  molho especial
  cebola
  picles
PAO COM GERGELIM

Eu simplesmente NÃO consigo fazer READ TABLEs de outra forma. As palavras reservadas abraçam as condições.

Não me zoa, sério.

Declarações de Variáveis

Eu tenho uma preguiça monstruosa de ter que declarar tudo daquele jeito enorme do ABAP. Acho muito chato… muito.

Se pelos dois tópicos anteriories você pensou “pqp que cara crica com a organização”, acalme-se comandante. Eu não ligo a MÍNIMA para como as variáveis são declaradas. Tanto que é bem comum ver coisas desse tipo nos meus códigos:

DATA: var1 TYPE bla.
DATA  var2 TYPE oi.
DATA: xyz TYPE 1234,
      hjs TYPE char200.

Não segue padrão nenhum, vou adicionando conforme vou criando e fico com um preguiça imensa de ajustar para ficar tudo em um só “DATA”.  Tento manter os vários DATA, TYPES e FIELD-SYMBOLs agrupados, mas nem sempre sigo esse padrão.

Basicamente, não estou nem aí. #shameonme

Eu tenho tanta preguiça que transformei isso em uma prática “positiva”: penso muito antes de criar uma variável. Quanto mais variáveis eu crio, mais me dá a sensação de que eu estou fazendo besteira e poderia ter resolvido com menos áreas de memória. Tudo para não precisar declarar.

(Tá bom… na verdade, esse último parágrafo sou eu me convencendo de que não sou um preguiçoso do kct).

IFs encadeados

Quando eu comecei com ABAP eu fazia muito isso aqui:

IF bla1 = bla1.
  IF bla2 = bla2.
    IF bla3 = bla3.
      IF bla4 = bla4.

       uma cacetada de código

      ENDIF. "bla1
    ENDIF. "bla2
  ENDIF. " bla3
ENDIF. "bla4

Eu pensava que isso ia me ajudar no código, mas depois de um tempo eu saquei a tremenda da besteira que é fazer isso. Se eu quiser ver qual é o IF, é só clicar duas vezes… Tudo bem que isso foi na época da 4.6 e a navegação dentro do debug antigo era muito zuada… mas não justifica. Isso é zoado.

Desde então, declarei guerra aos IFs encadeados. Fujo deles como diabo foge da cruz. Eu faço um esquema que eu gosto de chamar de “IF de exclusão”. Ao invés de usar o IF para dizer “faça a lógica maluca se o IF der certo”, eu digo “CAIA FORA se o IF falhar”.

Código acima reescrito:

IF bla1 <> bla1.
  EXIT.
ENDIF.

IF bla2 <> bla2.
  EXIT.
ENDIF.

IF bla3 <> bla3.
  EXIT.
ENDIF.

IF bla4 <> bla4.
  EXIT.
ENDIF.

Agora tenho CERTEZA que se o programa chegar aqui é pq ele tinha que chegar mesmo.
E o melhor: sem aquela zona de IF dentro de IF.

Isso vale não só para o EXIT, mas para CONTINUEs também dentro de SELECTs. Eu sempre coloco tudo que for IF de exclusão ante de qualquer lógica que eu vá fazer, tratando as mensagens  dentro dele. E assim eu também evito aquele programas bizarros com lógicas dentro de 3849348 IFs.

Aliás, os IFs de exclusão estão muito presentes no começo dos meus métodos e forms.

Aposto que não sou o único maluco

Mostrei para vocês minhas 4 principais manias quando estou abapando. Tenho CERTEZA que você também tem as suas. Quais são elas? Coloque ae nos comentários!

Abs a todos que roem unhas.