Legibilidade, nomes e if

Boas práticas, C# 1 Reply

Olá, tudo bom?

Hoje vou falar sobre Legibilidade. No dicionário: s.f. Qualidade do que é legível.

Vamos começar com uma contextualização do que é legível e depois passamos para a parte de código.

Contexto dia-à-dia

Bom, para começar, temos que pensar no nosso cotidiano. Vamos entender que, o que escrevemos é para outras pessoas lerem.

“Mas Octávio, e o que eu escrevo no meu diário pessoal e nos bilhetes grudados no monitor?”

Pense o seguinte: “Amanhã você será outra pessoa” (Momento motivacional). Assim sendo, você vai ter que entender o que escreveu e entender o motivo. De preferência também vai ter que lembrar o que estava acontecendo naquele momento, logo, para um texto ficar bom tem que expressar claramente o contexto em que foi escrito e seu objetivo de ser.

Um texto legível portanto, é aquele que deixa claro que você não está subentendendo que a pessoa tenha poderes alienígenas de ler a mente de ninguém, nem uma máquina do tempo para perguntar o que você estava querendo dizer no momento (afinal, isso também muda).

Enfim, se quiser que o que você escreva seja fácil dos outros lerem e entenderem de verdade, imagine que está escrevendo para uma criança que, de preferência, não seja superdotada.

Código

Ok, eu estou aqui para falar de código. Eu estou escrevendo baseado em textos que li e conteúdo que estudei, portanto, é a minha visão e interpretação, ficando a brecha para ser aplicado^^.

Nomes

Isso é um tema para livros, então vou tentar ser simples:

O nome do que quer que você esteja escrevendo deve, no mínimo, significar o que você quer que seja.

Uma função que carrega os dados da tabela pessoas não vai se chamar “GerarVerdeComBolinhas”. Portanto, busque representar o significado das coisas pensando que:

  • Métodos fazem algo portanto, uso verbos
  • Atributos representam algo portanto, uso substantivos
  • Classes também represento algo portanto, uso a lógica de cima
  • Não tenha medo de nomes grandes e sim de códigos gigantes por causa de uma toupeira que não sabia que o método já fazia isso

É simples: o código de um programador deve ser tão fácil e agradável de ler quanto um livro infantil.

Métodos e Classes

Um método faz o que seu título está dizendo que faz, o mesmo acontece nas classes. Se um código está contendo mais do que uma atividade então é simples, divida-o ou se a classe chama Ovo, os atributos de pintinho ficam na classe Pintinho. Seus métodos e seu código, quanto mais específicos, melhores de se entender, pois é um inferno ficar inferindo o que alguém está querendo dizer com as 2000 linhas de uma função “CriarConta”. Não preciso dizer o que ela deveria fazer né?

Propriedades, atributos, variáveis e parâmetros

Em C#, propriedades e atributos começam com letras maiúsculas, enquanto variáveis e parâmetros usam minúsculas. Isso é importante pra diferenciar seu objetivo, mas não só, para entender o que é privado, o que é do escopo, quem está dentro e quem está fora. Os seus nomes devem representar o que irão conter, pois todos representam caixinhas, que terão um conteúdo específico.

Condição If

A coisa mais usada na lógica é o tratamento de condição, assim como também deve ser a mais evitada. Entretanto, sendo um mal necessário, temos que fazer o máximo para ser compreensível de se ler e prático de dar manutenção.

O problema de um If é que “se alguém entender errado, todo o resto vai ser interpretado errado”. Certa vez discordei muito de pessoas que reclamavam disso, mas hoje eu entendo que há peculiaridades (bonito né) que desenvolve um belo “macarrão” em códigos com “ifs estranhos”.

Comparação negativa

Comparação negativa é feita com “== false” e não com “!”, pois se eu estou fazendo tudo correndo (como normalmente fazemos), eu NÃO VOU REPARAR EM UMA MINHOCA COM UM PINGO DEPOIS DE UM PARÊNTESE. Fica difícil parar para identificar os caracteres e quanto mais claro estiver na tela, melhor para identificar.

Chaves

Eu coloco “{” depois da condição e “}” no fim da condição, pois sempre vai ter uma toupeira que irá fazer algo assim:

Outra coisa é “onde enfiar as chaves”. Se você está programando em Java, use o padrão de Java, se for C#, use o padrão de C#, assim por diante, pois o programador tem que sentar na máquina e saber o que está fazendo e é a pior coisa do mundo ficar reaprendendo padrões mundiais por frescuras internas.

If com else ou return?

Busque um padrão!!! If com else tem duas opções dentro de uma função, ou você usa o else, ou você da um retorno:

E qual é o melhor modelo? Não importa, os dois são bacanas, mas deve haver um padrão. Não comece com else e termine com return, seu código deve ser consistente, ler tem que ser algo que siga uma linha e não uma feira cultural.

Encadeamento

Noooooooooooooo! Se seu if puder ser separado, melhor. O cérebro não é feito para tratar tantas condições de uma vez de forma consciente. Imagine que uma coisa é encadear uma vez, a outra é fazer o sistema todo encadeado (Neste momento eu passo a ser fã do modelo “return” citado anteriormente). Quebre seu encadeamento, nem que seja com outros métodos afinal, se existem tantas condições em um método, tem algo de errado com a lógica do “faça apenas uma coisa” e não ficar assim:

Na versão que costumo fazer, uso bastante do return e separo funções, para tentar tornar o código mais linear:

Claro, há quem não goste disso, mas a essência é ceifar encadeamento abusivo.

And e Or

Não adianta, or é difícil de processar, tanto para o computador, quanto para a nossa cabeça. Lidar com os || do C# é complicado e fica ainda mais difícil quando a condição fica muito grande. Assim, se puder, migre seus Ors para Ands. Tente inverter a condição, pensar do outro lado ou usar alguma coisa mais complexa, como um array, pois além de tirar a condição literal do Or, ainda torna a condição mais flexível e reutilizável:

 

Concluindo…

É isso aí, estas são as coisas que eu acho que mais pegam no cotidiano do leitor de código e que eu, também como desenvolvedor, acabo usando como ferramenta de tortura com nomes e ifs (todos erramos na pressa). Enfim, o que se pode tirar disso é que um código é um texto e deve ser escrito como um “O pequeno príncipe” e não  “Senhor dos anéis” ou “Prolegômenos a toda metafísica futura”, pois seu objetivo é funcionar e ser mantido exigindo que seja o mais rápido de entender possível.

Até mais,

 

One thought on “Legibilidade, nomes e if

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *