Hardcode, Constantes, C_Xs e derivados / ABAPZombie Guide 28 – CONSTANTS

Este post vai além de uma explicação de um comando…

Você já viu alguma vez em algum código fonte a seguinte declaração?

REPORT zombie_constante_idiota.

CONSTANTS: c_x TYPE c value 'X'.

👿

O QUE? VOCÊ JÁ ESCREVEU ISSO ALGUMA VEZ NO CÓDIGO?

👿 👿 👿

Neste post vamos entender para que serve este comando, e também entender porque constantes são úteis. Quem sabe, de uma vez por todas, o povo PARE DE CRIAR CONSTANTES SEM MOTIVO.

O comando CONSTANTS é usado na declaração de constantes, ou seja, variáveis com uma tipagem fixa e com um valor que nunca irá mudar em tempo de execução.

Exemplo:

REPORT zombie_constants.

CONSTANTS c_tipo_doc TYPE char4 VALUE 'WXYZ' .

Você pode usar a variável c_tipo_doc tendo a certeza de que seu valor nunca será alterado em tempo de execução. Você pode até criar uma “estrutura constante”:

REPORT zombie_constants_estrutura.

CONSTANTS: BEGIN OF c_estrutura,

            valor1 TYPE i VALUE '123',

            valor2 TYPE n VALUE '2',

            valor3 TYPE c VALUE 'A',

           END OF c_estrutura.



WRITE c_estrutura-valor1.

Ok, isso acaba com a explicação. Vamos agora à pergunta do milhão…

PORQUÊ EU DEVO USAR UMA CONSTANTE?

Imagine que você tem que fazer um programa que irá mostrar dados de uma deteminada empresa, e você terá que usar este código de empresa para fazer diversas seleções e validações dentro do código.

Se você sair escrevendo literalmente o valor desta empresa no código – por exemplo, IF empresa = ‘ZMB1’ – o seu código vai funcionar, mas se algum dia o código dessa empresa mudar de ZMB1 para ZMB2 você vai ter que alterar o código INTEIRO por conta de uma simples troca de valores.

Ao invés de espalhar o valor ZMB1 pelo código inteiro, você pode criar uma constante – por exemplo C_EMPRESA com o valor ZMB1 – e, se um dia o código mudar, você pode alterar somente UMA linha de código, para que seu programa fique correto e use o novo código de empresa.

HARDCODE E A BANALIZAÇÃO DAS CONSTANTES

Quem falou que programadores deveriam evitar hardcodes foi sábio. Mas em momento algum ele disse que TODO VALOR ESCRITO LITERALMENTE NO CÓDIGO É UMA CONSTANTE. Eu cansei de ver constantes C_X = ‘X’ espalhadas por códigos fontes. Isso é uma estupidez, porque o código fica horrível de ler, e o valor da variável não vai poder ser mudado nunca MESMO. Exemplo:

PARAMETERS: p_docto AS CHECKBOX,
            p_users AS CHECKBOX,
            p_soma  AS CHECKBOX.

CONSTANTS c_x TYPE c VALUE 'X'.

IF p_docto = c_x.
* Validações
ENDIF.

IF p_users = c_x.
* Validações
ENDIF.

IF p_soma <> c_x.
* Validações
ENDIF.

Se você mudar o valor de c_x para vazio, isso não quer dizer que todos os lugares onde C_X está sendo usado TEM de ser alterados. Ou seja, você criou uma variável que não precisava ser criada, que você nunca vai mudar o valor dela na declaração, e que deixou o seu código irritantemente mais chato de ler.

Pode parecer besta se eu colocar só contante burra de exemplo, mas eu já ví reports com mais de 20 contantes que não precisavam estar ali… e isso é um SACO para dar manutenção e debuggar. Eu já ví até projetos que obrigavam que você criasse constantes para todos os valores que você tivesse no código…

Uma só palavra quando eu vejo C_X e derivados no código: ZUADO.

PIOR é que eu já vi códigos onde a pessoa criou uma outra constante “esperta”, já que não podia alterar o valor da C_X:

PARAMETERS: p_docto AS CHECKBOX,
            p_users AS CHECKBOX,
            p_soma  AS CHECKBOX.

CONSTANTS c_x     TYPE c VALUE 'X',
           c_space TYPE c VALUE ' '.

IF p_docto = c_x.
* Validações
ENDIF.

IF p_users = c_space.
* Validações
ENDIF.

IF p_soma <> c_x.
* Validações
ENDIF.

OUTRO TIPO DE CONSTANTE BURRA

Colocar no nome da constante o mesmo que o valor dela é outro exemplo de constante BURRA e ABOMINÁVEL:

CONSTANTS c_ZMB1 TYPE CHAR4 VALUR 'ZMB1'.

Se um dia mudar ‘ZMB1’ para ‘ZMB2’ vai ficar fácil de entender que eu estou usando a C_ZMB1 num IF, mas, na verdade, ela vale ZMB2…

Vamos dar um nome para esse tipo de constante: Abominável Constante das Neves

MAS E AÍ, QUANDO EU SEI QUE TENHO QUE USAR UMA CONSTANTE?

Vale o bom senso e a correta análise da regra de negócio.

Se você tem um valor que você sabe que vai ser usado em diversos pontos do programa, que o cliente/funcional não deve nunca poder mudar sem requisitar uma alteração na especificação, e que importa para o PROCESSO do desenvolvimento (tipo de documento, uma empresa, um número de conta contábil, milhões de exemplos aqui), use uma constante.

Se o caso for igual ao acima, mas o cliente/funcional podem querer alterar ou expandir os valores, vá de TVARV (vou explicar sobre a TVARV num post futuro).

Porém, se o seu caso não se encaixar neste dois, ou for usado somente em um lugar do código… coloque o valor literal e seja feliz. 🙂

Abraços à todos aqueles que já discutiram com pessoas que acreditam que o uso de C_X em códigos com mais de 10mil linhas é correto.

😉