Código Limpo – Parte 02

Boa noite pessoal, tudo bem?
Vamos continuar com o assunto de como manter um código limpo? A primeira parte do assunto, você encontra aqui: Código Limpo – Parte 01.

Falemos um pouco sobre variáveis de escopo e atributos.

OBS.: Toda vez que eu escrever atributos eu estarei me referindo aos dois casos, ok? Tanto como variáveis de escopo (parametros de métodos, definições de variáveis dentro de loops), tanto quanto atributos de classe. Apenas para não ter que repetir atributo/variável toda hora aumentando o texto.

    • Usar camelCase no nome do atributo – essa dica é uma dica básica e bastante encontrada por aí. Facilita a leitura e é utilizado em convenções de várias linguagens de programação. Alguns exemplos seriam:
          String disapprovedStudent;
          double totalDivide;
          boolean isManager;

      Uma vantagem é que é mais fácil ler na forma camelCase do que:

          List player_own_goals;
          List playerOwnGoals;

      Uma desvantagem seria em um nome grande:

      Map allYellowHousesFromTheBlock;

      Ou seja, utilize e não abuse. ;)

    • Nome de lista no plural – para que colocar nome “listaPessoa” se colocar “pessoas” já dá o mesmo sentido? E existe uma diferença enorme entre pessoa e pessoasanalisando o conceito da palavra. Mantenha esse conceito em mente e verás como seu código ficará legível. Veja só o “foreach” como ficaria:
          List houses = new ArrayList();
          // adds the houses from the block at the list
          for (House house: houses) {
              this.ringBell(house);
              this.runForYouLife();
          }

      Perceba que ao ler o nome da lista “casas” fica claro que estamos falando de um conjunto de “casa”. Quanto mais frequente esse tipo de nomeclatura for utilizada em seu sistema, mais claro ficará para quem estiver lendo, o que o atributo significa e o seu valor no método.

    • Devemos dar nomes reais que sejam fáceis de falar, nomes que se “auto-expliquem”. Imagine só, caso você visse a seguinte declaração:
      public class Car{
          //... some code
          boolean caCra;
          //... some code
      }

      O que ela deve significar? Qual seria sua utilidade? Como se fala? Imagine você chamando seu colega de trabalho, e ao tentar explicar o que estás a fazer, ele pergunta: “Ta, mas você está falando de qual atributo?”! Como você falaria?
      Sendo o nome direto, objetivo e “falável” você já pode imaginar o que significa, e ao comentar o código com alguém, seria mais fácil de ser dito e a pessoa que o ouvir poderia se lembrar dessa parte do código facilmente. Ah sim, qual seria o nome mesmo daquele atributo?

      public class Car{
          //... some code
          boolean isCarCrashed;
          //... some code
      }
    • Caso você veja o código a seguir, cuidado pois ele pode trazer muito entendimento incorreto:
          int value1, value2, value3;
          // ou
          String name1, name2, name3;

      O que poderia significar o um, dois ou três? Veja que em nenhum momento o atributo dá a entender onde deveria ser utilizado, e qual seria sua função. O código fica difícil de entender. Caso você tenha o azar de cair em if/else/while aninhados com esse tipo de atributo, é hora de levantar e ir pegar um café por que a tarde será longa… Imagine a seguinte situação:

          String str1, str2, str3, str4;
          //... some code
          str4 = str3.substring(4,8) + str1.concat(str2);

      Agora, imagine se o código tivesse sido escrito assim:

          String userLogin, userPassword, lastLoginDate, userAccessKey;
          //... some code
          userAccessKey = lastLoginDate.replaceAll("/", "-") + userLogin.concat("-" + userPassword);

      Conseguimos entender o que esse código está fazendo apenas pelos nomes dos atributos. Se estiver dentro de um método que tenha um nome claro então… Faz a combinação para deixar qualquer programador que leia o seu código feliz. Eu vi um caso em que semanticamente (pois era um estudo de OO) ao qual não haveria outra possibilidade de se colocar nomes que não tivesse 1 e 2 no final. Caso você tenha em mente o mesmo conceito e percepção, de que o projeto perderia coesão e sua definição se os atributos não tivessem o número no final, vá em frente e implemente seu código.

    • Os nomes dos atributos têm que sempre manter sentio ao contexto ao qual estão sendo utilizados. Sempre que ao ler o nome de um atributo ele tem que fazer sentido no trecho em que está aparecendo.
          //... some code
          int total = 0;
          for (Trade tradedBall : tratedBalls) {
              total += tradedBall.getTotalTratedItens();
          }
          for (Trade tratedHelmet : tratedHelmets) {
              total += tratedHelmet.getTotalTratedItens();
          }
          StockFacade stockFacade = FacadeFactory.getStockFacade();
          stockFacade.updateAmountTratedItens(total);
          //... some code in the same method
          //...
          //... 15 lines after
          double totalSpent = financialFacade.calculateSpentValue(spentValuesWithEmployees + (valuePerIten * total));
          return totalSpent;

      Quem é esse total que apareceu do nada ali no cálculo final? De onde veio esse valor? Qual o papel dele nesse método? Agora, imagina se ao invés de total fosse totalItensTrocados? Leia o código novamente trocando o total pelo nome sugerido.
      Essa é a diferença de se manter um nome que sempre tenha valor no contexto em que está sendo utilizado.

    • Não especificar na frente do nome do atributo o seu tipo. É muito comum se encontrar intIdade, strNome, dtNascimento. Você pode se perguntar: Que mal há nisso? Lembre que uma das boas práticas seria o fato do próprio nome do atributo se “auto-explicar”? Colocando o atributo na frente existem algumas desvantagens:
      • Incentivo às más nomenclaturas – é muito mais fácil pensar em colocar dtNascimento do que dataNascimento. Com isso, a idéia de nomes “auto-explicativos” iria começar a falhar. Poderiam nomes estranho como dtNas ou dtMNat (dataMorteNatural).
      • Variação na abreviação do tipo – seria fácil começar a encontrar algumas variações como: strNome, stNome, sNome, ou nmNome(se fosse apenas nome resolveria). Até aí nada de exagerado, agora imagine se sua aplicação tem um javascript e nele você começa a ver: cbDtIni ou então txNmCp. Qual seria a sua reação? Você saberia explicar cada um deles? Creia em mim, não é exagero, eu já vi atributos com esse tipo de nome.

      Evite esse tipo de prática, esse tipo de nome nos seu atributo irá causar uma leitura de código demorada e trabalhosa.

  • Já pensou em ter atributos de nomes pequenos e fáceis de digitar? Suponhamos que em seu programa você tenha uma variável chamada “todosOsAliensDoUniverso”. Agora imagine você tendo que digitar isso toda vez… Se bem que se essa variável se chamasse “aliens” seria… hum… Bem mais fácil de digitar e deu a entender que é uma lista. Não tem hora que você está fazendo aquele código legal e você pensa: “Caramba, tenho que digitar esse nome de novo?!”. Com um auto-completar hoje das IDEs tem ficado mais facil, mas imagine a pessoa ter que escolher entre 5 nomes toda hora, sendo que ela poderia estar a digitá-caso ele fosse pequeno…  Lembre-se, o nome de um atributo não deve afastar pessoas.
  • Espaço entre seus atributos – um código que envolva cálculos sem espaço entre seus atributos, fica um código que causa dor de cabeça! Vejamos um exemplo:
    total=salesPerDay(today)-(COMMITTEE_PERCENTAGE*vendors+totalSoldItens);

    Um código ganha mais clareza quando se tem espaços entre seus atributos:

    total = salesPerDay(today) - (COMMITTEE_PERCENTAGE * vendors + totalSoldItens);
  • Evitar o envio de atributos nulos – o envio de atributos nulos é a raiz de muitos nullPointers! Imagine só, você está acessando um método que nunca usou, mas falaram para você: “Vai lá, coloque o código chamando o método e envie o produto para o cliente. Pode confiar que esse método nunca deu erro!”. Só que não te explicaram que não poderia passar null. Com isso, uma imagem muito feia apareceria para o cliente e a confiança do cliente no programa ficaria afetada.

Bem pessoal, espero que esse artigo de hoje possa lhes ajudar.

Esse assunto terá continuação.

Até mais. [=

6 thoughts on “Código Limpo – Parte 02

  1. Yo Hebert,
    Estou lendo essa sessão de dicas porque boas práticas sempre é um assunto interessante, ainda mais quando se é novato em Java, meu caso, onde o aprendizado correto é primordial pra evitar dores de cabeça no futuro.
    Obrigado por compartilhar tais posts.
    Vou para a terceira parte agora.
    []’

    • Olá doutorcrimsondo, boa noite.
      Eu desaconselho essa prática por dois motivos
      1) Padrão JavaBens determina que tem que ser ou com is ou com get. Um framework como JPA, JSF, EJB e outros precisam que esse padrão seja utilizado para o correto funcionamento
      2) O problema com o “eh” é que se trata de representar uma palavra de modo fonético e não na gramática culta. Uma pessoa mais antiga poderia não entender que o eh significa é.

      Obrigado pela visita

Leave a Comment