Já encontraram o valor de X?
Um problema que muitas vezes é subestimado (e as vezes confesso superestimado) no mundo da programação, tange o nome de uma variável. É perfeitamente factível escrever nomes de variáveis temporários quando estamos montando a nossa solução lógica, mas eles devem ser substituídos por opções melhores ao finalizarmos nosso trabalho.
Considere a seguinte implementação em swift:
O que este metodo faz? Converte uma temperatura que esteja em uma unidade de temperatura para celsius. Qual unidade? Olhando a chamada do mesmo parece que tudo está certo. A leitura da chamada do método flui. Qual o problema então? Se chegar um desenvolvedor que não conheça a fórmula de conversão de uma temperatura em farenheit para uma temperatura em celsius provavelmente ele não vai entender este código. E tem um outro problema, o nome result ali que armazena o resultado da operação também é muito vago. Uma sugestão de melhora deste código adicionaria um nome interno farenheit para ser utilizado dentro da fórmula e trocaria o nome da armazenadora do resultado, algo como:
O objetivo aqui é ser sempre o mais claro possível, para que até quem não trabalha com desenvolvimento consiga entender, na medida do possível.
Vamos analisar um outro caso:
Perceba que temos aqui a separação dos parâmetros como citamos anteriormente mas ainda assim podemos melhorar alguns pontos do código. Olhando apenas na linha 4, não fica nada claro que "vc" é a LoginViewController. Mesmo que "vc" seja uma abreviação de ViewController aparentemente óbvia, neste caso referenciamos um tipo específico e ele deveria estar presente no nome da variável. Um exemplo de como melhorar o código acima pode ser visto abaixo:
Melhorou um pouco não? Mas ainda temos problemas na linha 3. "data" é um nome muito genérico e para quem está fazendo um skimming do código procurando por algo não fica muito claro do que se trata. As perguntas que devem ser feitas são: Estou corrigindo um bug aqui, qual o problema? Da onde vem essas informações que chegam no método? Se eu fizer um jump para a definição do tipo LoginData obviamente vou descobrir muitas respostas, mas perceba que eu tive que fazer um passo a mais e facilita se eu só olhando já consegui descobrir o que preciso. Abaixo uma proposta de melhoria para o código acima.
Agora trataremos do caso contrário, quando queremos ser explícitos, mas acabamos programando como no tempo do (saudoso) Objective-c. Analise o código abaixo:
O problema aqui é exatamente o oposto. "userDocumentWithoutPhotography","userDocumentWithPhotographyAndPrint", e "userAddressWithComplement", são nomes muito grandes e difíceis de ler e interpretar rapidamente. Para o documento, a solução está um pouco mais na nossa mão: "userDocument" e "userDocumentWithImage". Para o endereço completeUserAddress é uma boa saída. Não é um problema de digitação, afinal o Xcode autocompleta pra gente (ou quando é uma declaração não é difiícil escrever). O ponto aqui é facilitar a leitura rápida e entendimento do código sem que o desenvolvedor tenha que ficar "lendo livros de código".
Interessante notar que nada disso vai sair se a gente ficar sozinho escrevendo código e conversando com a nossa mente. Algumas respostas até podem surgir, mas a melhor estratégia é compartilhar/mostrar o código para colegas de trabalho que não terão a cabeça enviezada com os seus pensamentos. O que vale aqui é o diálogo, que deve ser feito ainda antes do Code Review. A lição que fica é que programação é uma tarefa que exige atenção aos detalhes e quanto mais claro for o código, mais fácil é sua manutenção e criação. Até a explicação para um leigo, se o código for bem escrito, fica fácil. Não há uma resposta certa para tudo e cada caso é um caso, mas sendo sensatos e conversando, conseguimos deixar o código legível, organizado e limpo.
