Guias

Published on September 1st, 2011 | by Mauricio Cruz

14

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?

👿

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:

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”:

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:

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:

FUUUUUUUUUUUUUUUUUUUUUUUU

OUTRO TIPO DE CONSTANTE BURRA

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

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.

😉

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Email this to someonePrint this page

Tags: , ,


About the Author

é pasteleiro há alguns anos e criou o ABAPZombie junto com o Mauro em 2010. Gosta de filosofar sobre fundamentos básicos da programação e assuntos polêmicos. Músicas estranhas, artes marciais e games indies são legais. Zumbis não. Converse comigo no twitter e conheça o meu livro de ABAP!



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

  1. Gustavo says:

    Show de bola esse post!

  2. Daiane says:

    Você disse tudo!!!!!! Também acho que houve uma banalização das constantes… e daí vem a "síndrome do robô" e não analisa a real necessidade do hardcode.
    Eu já briguei, bati o pé, pois no QA queriam que eu retirasse os hardcodes 'X'…. AHHHHHHH!!!!!
    Mas, como eu tenho juízo eu obedeço (mesmo totalmente contrariada) rsrs

  3. Isso é realmente uma das coisas mais simples e irritantes que existem, não só em ABAP como em qualquer linguagem. E usar a TVARV acaba com aqueles chamados abertos só pra alterar um C_BUKRS ou C_WERKS.

    Além disso, C_X é um absurdo quando usado para testar flags… custa usar NOT … IS INITIAL?

  4. Fábio Pagoti says:

    Sem dúvida, muito ABAPeiros tem essa mania e que acaba sendo contagiosa (já fiz muita constante burra – e não por opção).
    Caso alguém não esteja convencido de que este post tem total sentido, economize ao menos o c_x e o space (ou c_space) pelas constantes abap_true e abap_false.

    Abraços!

    • Sim!

      Acho que quase todas as liguagens tem uma constante já pronta para true ou false, e para o ABAP não é diferente.

      E eu também já fui obrigado a fazer constantes burras, mas isso não durou muito – e acho que por isso que eu já entrei em tantas discussões enérgicas sobre hahaha

  5. Uma vez alterei um programa gigante que tinha constantes burras, fiquei na duvida se mudava também o nome da constante rsrsrs, deu muito trabalho, mas fiz o melhor que pude rsrs…

  6. Custodio says:

    abap_true e abap_false sao (boas) gambetas da SAP ja que o ABAPao nao tem "booleans reais". acho que de todos os exeplos do post o pior eh o tal de c_zmb1.

  7. Uma explicação que ouvi uma vez para o uso de C_X ou C_ZMB1 é que a empresa usava um programa para detectar literais no código e com as aberrações acima o programador enganava esse programa e assim evitava a dor de cabeça de ficar justificando o uso do "X" como hard code!

    Ainda acho que a sugestão do Fábio muito boa. Eu mesmo adotei até nos treinamentos que ministro o uso de abap_true e abap_false.

    Abs!

  8. Julio says:

    Cara, eu também já passei por essa de TER que colocar C_X… Tantas vezes que já peguei esse vício maldito e lembro de diversos códigos meus poluídos por constantes burras…

  9. Galera,

    Só para lembrar, aqui no abapzombie tem uma classe para auxiliar nas seleções de parâmetro da STVARV, segue o link:
    http://www.abapzombie.blog.br/dicas-abap/2011/01/

    Segue o tuto de como criar migrar uma classe local para uma global:
    http://www.abapzombie.blog.br/dicas-abap/2011/01/

    Sem zombizadas galera =D
    Abs,

    Mauro

  10. Paulo Rios says:

    Cara, muito bom esse post. Já declarei muita constante burra por que o QA enche o saco. É ridículo mas o C_X é bem freqüente nos programas que vejo. Agora vou evitar ao máximo e indicar esse post aos que ainda relutam em criar constantes burras…

    Abraços!

  11. Vivian says:

    Muito bom! Eu mesmo usava isso pensando que estava correto, não por ter a “síndrome do robô”, mas por simplesmente pensar que era melhor e pronto, sem pensar no real uso de constants. Ótima explicação e com certeza irei levar para toda a vida! rsrs

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top ↑