Mais importante do que fazer um código que funcione é fazer um código bem feito. Mas você sabe o que é que faz um código ser realmente bom?
Livro sempre em alta no meio da comunidade dev, o Código Limpo, de Robert C. Martin, é considerado já um clássico de leitura e algo que todo bom programador deve ler em algum ponto da sua vida. Ele trata não apenas de qual é a maneira ideal de se programar um bom código, mas sim de como fazer dele uma legítima obra de arte.
Nós, do meio da programação, costumamos esquecer que os nossos códigos são trabalhos como quaisquer outros. Por isso, eles também estão submetidos a alguns valores e princípios que dizem o que é bom e bem feito ou não, na medida em que são avaliados pelos valores do bom, do belo e do verdadeiro, e quanto mais ele atender a esses princípios, tanto mais valioso, bem-feito e apreciado ele é. Portanto, é sim possível que o seu código seja funcional, mas seja péssimo. E, até certo ponto, é esse um dos fatores que diferenciam o programador júnior do sênior.
Por que um código ruim é tão mal?
Dificilmente um programador ficará na mesma empresa durante todo o tempo de vida de um código. A rotatividade acontece, dev’s vêm e vão, e normalmente aquilo que você escreveu “viverá” mais tempo na empresa que você mesmo. Por isso, se o seu código for difícil de se entender, ele poderá atrapalhar toda a empresa. E isso não é uma atitude justa e ética, já que você atrapalhará totalmente o andamento de um ambiente que emprega diversas outras pessoas que trabalharão com o que você escreveu.
Além disso, imagine que você, por acaso, acabe ficando pelo menos cinco anos nessa empresa. Aconteceu que você, há cinco anos atrás, escreveu um código extremamente preguiçoso; agora, meia década depois, você precisa revisitar a sua obra e percebe que você não faz a menor ideia do que está ocorrendo.
Você foi a causa, o autor do mau código, você é o culpado e você foi o atingido. Agora você está fadado a passar horas de estresse, preguiça, programando por má vontade e se pondo em risco de sofrer um burnout. Isso tudo por causa da falta de código limpo!
O meme acima, apesar de ser bastante conhecido, de maneira alguma deve servir de exemplo. Métodos de programação como o XGH não são aceitáveis para um profissional de respeito e você definitivamente não está sendo pago para isso.
A falta de código limpo é péssima para o trabalho em grupo
Esses exemplos atrás tratam de casos individuais; no entanto, a realidade é que, via de regra, você trabalhará em grupo com outros programadores que devem entender o que você fez . Ferramentas como Git e GitHub garantem que todos os membros de uma equipe poderão trabalhar em cima do mesmo código. Facilmente o projeto se tornará uma loucura ainda em desenvolvimento caso sua qualidade não seja observada e mantida.
Em sua obra Código Limpo, o Uncle Bob chegou a falar que ele conheceu uma empresa que foi realmente à falência pelas falhas em seu código-fonte. Elas se acumularam ao longo das décadas ao ponto em que nenhum programador era capaz de fazer nada e a aplicação estagnou no tempo. Ela foi, então, esquecida pelo público e engolida pela concorrência, chegando a falir.
E isso se dá por um motivo muito simples: ao começo de um projeto, a equipe avança a passos largos, codificando da forma mais rápida possível, de modo que a tarefa esteja completa em tempo recorde. No entanto, conforme os dias se tornam meses e os meses se tornam anos, o código se torna cada vez mais entulhado, cheio de módulos sem sentido e mal organizados, e com isso a produtividade cai consideravelmente.
Assim, com o tempo, o projeto precisa ser completamente refeito; com isso, mais trabalho é feito, alguns programadores são demitidos, outros postos para dentro e toda a empresa é prejudicada e avariada. Tudo isso para, depois de uns anos, todo o processo ser refeito, porque novos módulos foram feitos sem a merecida atenção.
O código limpo, porém, é uma obra de arte
Como citado anteriormente, um código bom é julgado como toda obra de arte: o quão belamente bem feita ela é influencia diretamente em se ela é uma boa obra ou não. É por isso, por exemplo, que o programador é chamado autor do código. Aqueles que virão depois de você lerão o seu código, e, na verdade, eles devem não só entender o que foi feito, como também ficar admirados e espantados com o quão funcionalmente simples ele é. Tudo faz sentido, tudo está onde deveria estar, e o código é verdadeiramente elegante.
Para tanto, o Robert Martin, autor do Código Limpo, separou algumas citações de importantíssimos programadores que pincelam por cima o que é um bom código. Traremos algumas aqui:
- “Um bom código possui poucas dependências, as quais são explicitamente declaradas e oferecem um API mínimo e claro” – Dave Thomas, fundador da OTI
- “Um código limpo sempre parece que foi escrito por alguém que se importava” – Michael Feathers, autor de Working Effectively with Legacy Code
- “Redução de duplicação de código, alta expressividade e criação no início de abstrações simples. É isso que torna para mim um código limpo” – Ron Jeffries, Autor de Extreme Programming e Extreme Porgramming Adventures in C#
- “Um bom código faz parecer que a linguagem foi feita para o problema” – Ward Cunningham, criador do conceito de “Wiki”, criador do Fit, cocriador da Programação Extrema
Com isso, nota-se que o código limpo é, então, uma legítima obra de arte. Um bom código é algo bom de se ler, e certamente você não irá queimar seus neurônios buscando entender o que está acontecendo. Tudo está onde deveria estar, nem acima e nem abaixo. As variáveis e funções têm bons nomes, tudo está muito bem modularizado e você tem a sensação de que o código é um todo conciso.
Como escrever, então, um código limpo?
Existem algumas boas práticas que podem facilmente ser absorvidas e entendidas para tanto. No entanto, antes, devemos expor bem um fato: se você está no começo dos seus estudos como programador, não se preocupe ainda com o código limpo. Se preocupe com o entendimento dos conceitos básicos, queira por agora aprender a programar. Depois você pode pensar mais no quão belo é o seu código.
Para tanto, existem diversas pequenas dicas as quais todos podem seguir, mesmo os programadores mais iniciantes. São coisas realmente simples, como regras básicas para nomes. Vamos ver quais são:
Use nomes significativos
O nome do seu código deve ser algo que tem significado em si mesmo. Isso é, quando o leitor ler o nome de uma função ou de uma variável, ele deve entender o que está acontecendo.
Como podemos ver no exemplo acima, “yyyymmdstr” não quer dizer absolutamente nada. “dataAtual”, porém, é autossuficiente e autoexplicativo. Realmente faz todo o sentido, e o seu leitor facilmente compreenderá do que se trata.
Use nomes pesquisáveis
É importantíssimo que o seu nome seja algo lógico para que possa depois se pesquisado no código. Na maior parte do tempo, acabamos nos esquecendo do local de algo. Com isso, usamos o atalho control + F o tempo todo, e precisamos dar um jeito de nos localizarmos no código. É por isso que, ao pesquisar, precisamos conseguir encontrar o que queremos.
Por exemplo, o que significa o número 86400000? Absolutamente nenhum, é algo quase inútil. É por isso que criamos a constante MILISSEGUNDOS_POR_DIA: ela tem sentido por si mesma. Note que constantes como essas, que serão usadas várias vezes por código, devem ter seu nome em caixa alta!
Os nomes das funções devem dizer o que elas fazem
Primeiro, precisamos frisar que as funções são os verbos do seu código, enquanto que as variáveis e constantes são os substantivos. As funções são ativas, e as variáveis são as palavras que preenchem os lugares vazios e explicam cada atividade. Por isso, nomeamos as funções com verbos: criarNovoUsuário, por exemplo, é um ótimo nome para uma função que, obviamente, cria um novo usuário.
Agora, precisamos frisar que os nomes devem explicar exatamente o que uma função faz.
No primeiro exemplo, adicionarNaData não diz nada. Adicionar o quê na data? Fica a questão. E não deve ser assim: seu código deve se explicar por si só, lembre-se! Por isso, adicionarMesNaData é muito mais apropriado: ele recebe um mês e uma data, e adiciona o mês na data. É muito mais simples e entendível.
Encapsule condicionais em variáveis
Às vezes, é bastante difícil de entender condicionais. Elas podem chegar a ser bastante complexas, envolvendo várias variáveis e vários testes de uma só vez. É por isso que é sempre bom encapsular a condicional: criar uma função para ela, de modo que retorne o true ou false para rodar no bloco if/else.
Além de ser muito mais sintático e simples de se entender, isso permite até o reuso de uma mesma condicional em outras partes do código. Com isso, você pode reaproveitar a função várias vezes, e modificá-las todas de uma vez ao mudar uma só função.
Conclusão
O código limpo é uma boa prática à qual todos os programadores devem estudar e entender, mas não devemos tratá-la como urgência absoluta também. Caso você esteja no início da sua carreira, foque mais em aprender os básicos; no entanto, se você já sabe de uma coisa ou outra, é crucial que você procure fazer códigos de maior qualidade. Isso envolve também uma melhoria na estrutura de dados, assunto que talvez abordemos aqui futuramente.
Baseamos esse texto em alguns outros, como esse artigo no GitHub que é um resumo do livro Clean Code, no próprio Código Limpo original de Robert C. Martin e também nessa série de resenhas sobre a obra supracitada.
