Código Limpo – Parte 04

Olá, tudo bem? Para melhorar nosso código, vamos continuar o estudo sobre código limpo? Os outros artigos estão aqui: Parte UmParte DoisParte Três.

Hoje será abordado Constantes e Exceptions.

  • Formato do nome – A constante tem seu nome escrito em caixa alta “COR”; e separado por “_” quando é um nome composto: “GOL_CONTRA”. Não começar com “_” pois não existe necessidade, essa técnica era utilizada em outras linguagens para diferenciar método de atributo.
  • Nome define o uso – Uma constante fica clara graças ao se nome, que deve ser objetivo. Ela deve ser entendível onde quer que seja utilizada. Caso você tenha uma constante de log, por exemplo, utilizando apenas LOG como nome não seria tão claro como LOGGER. A diferença é clara quanto à própria definição da palavara, LOG é algo gerado e LOGGER é quem gera. Não importa onde esteja o nome LOGGER, sempre conseguiremos entender a função dessa constante.
  • Quando constantes são necessárias – Devemos sempre estar atentos quanto a repetições. Sempre que estamos repetindo uma ação ou valor tem algo errado acontecendo. Vamos supor que temos um método que altera o placar em uma partida de futebol:
    public void changeScore(Team team, int goal){
        this.fullScore(team, gol);
    }

    E esse método é utilizado da seguinte forma para registrar um gol contra:

    public void recordOwnGoal(Team team){
        match.changeScore(team, -1);
    }

    Imagine toda vez que fosse necessário informar um gol contra a algum método; teríamos sempre que escrever o “-1″ por exemplo:“registrarGolParaJogador(jogador, -1);”. Por que não criar uma constante? Com essa constante iríamos poder eliminar um método. Veja como o processo final para registrar um gol contra ficaria:

    //Our declared Constant in the Match class.
    public static final int OWN_GOAL = -1;
    
    public void changeScore(Team team, int goal){
        this.fullScore(team, goal);
    }

    Note que não existe mais a necessidade de utilizar o método “registrarGolContra”, pois a única razão de sua existência era colocar o valor do gol como negativo. Com isso, ao chamar o método alterarPlacar bastaria passar a constante GOL_CONTRA ao invés de ter que chamar/criar um método para isso ( alterarPlacar(time, GOL_CONTRA); ). Constantes são muito bem vindos por exemplo, em construção de templates: “ADICIONAR_LINHA_SIMPLES”, “ADICIONAR_LINHA_COMPOSTA”, “PARAGRAFO”, e outros mais. Basta notar, está sempre tendo que passar um mesmo valor? É hora de utilizar uma constante.

  • Existe uma razão, qual é? – Ao criar uma captura de exceção devemos nos ater ao porque daquela captura. Devemos sempre focar no fato de que, se algum método declara que uma exceção pode ser lançada, um tratamento deve ser dada para ela. Devemos sempre ver o melhor modo de tratar esse infortúnio, alguns exemplos seriam: o que mostrar ao usuário (exceção tratada), como tratar as ações inacabadas (arquivos, transações com db, log, etc).
    Ao ignorar um exceção, não tratando seu objeto do tipo “Exception”, estamos simplesmente desrespeitando o contrato do método o que poderia acarretar problemas para o usuário e à sua aplicação.
  • Exception impossível de acontecer, mas é declarada? Certa vez enquanto alterava um código, notei que ao testar a funcionalidade ela não funcionava e não apontava erro. E mesmo revisando meu código ví que ele estava correto e não achei problema algum.
    O que fazer para achar o erro? Debug!
    Comecei a percorrer o código e me deparei com o seguinte código:

    //...
    validateCreditCard(creditCard);
    //...
    }catch(CreditCardInUseException){
        //Impossible to get here
    }

    Quando o método de validar cartão crédito foi criado realmente não havia a possibilidade de o cartão estar em uso, e por isso o comentário descrevia que seria impossível chegar ali. Mas vemos nesse caso dois pontos passíveis de melhorias:

    1. Método não coeso – note que o método de validar o cartão lança uma exceção que às vezes é valida e outras não. Existe dentro deste método uma regra de negócio que diferencia seu comportamento, e a diferença de comportamento altera o tratamento dado a sua assinatura (futuro assunto sobre OO); uma solução seria separar esse método que está tendo tantos comportamentos diferentes, pois ele está em um estado “delicado” tendo muitas decisões dentro dele.
      Para uma exceção acontecer, ela deve ser tratada e em nosso caso – quando o código foi criado – não tinha como acontecer nenhum tratamento. Se existe um método que declara uma exceção que nunca irá acontecer, tem algo errado!
    2. Se uma exceção é lançada, ela tem o seu motivo e ela deve ser tratada. Perceba que se a exceção estivesse sendo tratada, e no mínimo, com “System.out.println();” haveria uma mensagem informando que algo aconteceu. Digo no mínimo, pois poderíamos dar diversos tratamentos como registrar em log, enviar email, etc. Algo estava acontecendo, uma exceção sendo lançada, mas nenhuma ação estava sendo tomada. Lembre-se: “Se uma exceção é lançada, existe um motivo e ela deve ser levada em consideração.”.
  • Mensagens de erros claras – As mensagens de erros devem ser claras, de modo que um usuário possa entender. Afinal, é ele quem estará lendo e tem a “obrigação” de entender. Evite mensagens como: “Ação Ilegal!” ou “Erro!”. Esse tipo de mensagem não esclarece em nada o usuário, e pelo contrário, apenas fará com que ele fique mais confuso.
    Um bom momento de se escrever as mensagens de erro é enquanto se desenvolve/refatora a função, pois você estará ciente de todo o processo.
  • Escrevendo mensagens de erro – Ao escrever uma mensagem de erro evite pensar: “Vou colocar a mensagem assim, pois está bem claro que é sobre esse assunto que estamos falando.”. Será? O usuário não pensa como desenvolvedor, ele não tem que saber que o valor X vem da tela Y e é necessário para chegar à tela Z.
    Quando estiver em dúvida de como colocar a mensagem, olhe para tela e tente esquecer tudo o que você sabe sobre ela e pense: “Sendo alguém que nada sabe sobre desenvolvimento, como entenderia melhor essa mensagem de erro?” Adapte essa pergunta ao que você está desenvolvendo, mude seu modo de pensar e mantenha seu foco no usuário. Uma outra boa opção é chamar um colega do trabalho para dar uma opinião.
  • Evite certas mensagens de erro ao desenvolver – Enquanto estiver a desenvolver, evite mensagens como: “Ta vendo? Por sua culpa gerou erro!” ou “Seu Zé Mané, digita alguma coisa aqui!”. Às vezes é divertido e até mesmo gera certo alívio quando uma mensagem desse tipo é exibida, mas é aí que mora o perigo. Imagina se essa mensagem permanece salva no código e é enviada ao cliente. Por mais divertido que seja, é melhor evitar.
  • Log4J – Uma boa ferramenta que poderá ser util na hora de registrar exceções é o Log4J. Com essa biblioteca é possível registrar log em diferentes tipos de níveis e outras opções mais. Pretendo ainda escrever um tutorial sobre ela, mas enquanto não fica pronto, vai aí uma dica para quem se interessar: http://www.guj.com.br/article.show.logic?id=130

Espero que essas dicas possam ter ajudado.
Até a próxima pessoal.

2 thoughts on “Código Limpo – Parte 04

Leave a Comment