Estilo de código: o que tode dev júnior PRECISA saber
A área de desenvolvimento de software é um tanto quanto peculiar quando se trata de fundamentos e verdades absolutas: são poucas as frases de efeito que são aceitas por unanimidade e não são seguidas daquele poderoso depende.
Um dos poucos fundamentos que normalmente sobrevive discussões é sobre a importância da estilização do seu código. É claro que há muita discordância e treta pela internet sobre qual estilo usar, mas ao menos todo mundo concorda que estilizar o código é essencial em diversos casos.
Este artigo não vai te apresentar nenhuma visão sobre qual estilo de código é o melhor, ou criticar estilos existentes. A minha intenção é munir você, dev júnior, com as ferramentas básicas que vão te ajudar a entender a importância da estilização de código e como isto vai afetar o seu aprendizado daqui pra frente - até o fim da sua carreira.
Dev júnior escreve pra computadores, dev sênior escreve pra pessoas
O motivo principal de eu escrever este artigo é que depois de várias sessões de mentoria com iniciantes tanto no front-end quanto no back-end percebi que muitas das confusões e dificuldades que essas pessoas tiveram poderiam ser mitigadas com a adoção de algumas boas práticas sobre estilo de código.
Eu já perdi a conta do número de sessões em que mentorandes chegaram para mim com quilos e mais quilos de código para resolver problemas simples, sem entender o que aquele espaguete estava fazendo. Ao mesmo tempo, já compartilhei códigos super complexos que qualquer júnior com o mínimo de conhecimento consegue entender e modificar.
A diferença é simples: dev júnior costuma escrever código que máquinas apenas entendem, enquanto dev sênior costuma escrever código para que pessoas entendam.
O maior erro de quem inicia na programação é achar que a forma como se escreve código não faz diferença. Vejamos um exemplo:
const words = ['Hello', 'world']
let sentence = ''
for (const i in words) {
sentence = sentence.concat(words[i])
if (i < words.length - 1) sentence = sentence.concat(', ')
}
console.log(sentence)
O código acima deverá cuspir na tela o valor Hello, world e nada mais, certo? Errado!
O código acima cria três variáveis e deixa duas delas no escopo local, sem contar no montante de operações desnecessárias. Na verdade, o código acima poderia ser simplificado para algo assim:
const sentence = ['Hello', 'world'].join(', ')
console.log(sentence)E aqui eu deixo claro o seguinte: código complexo é diferente de código complicado!
Uma boa definição de complicado que se adequa ao que quero dizer, lá do dicio, é algo "Exageradamente detalhado; que possui elementos em demasia [...]".
Enquanto a definição de complexo por lá nos diz que é uma "Construção com inúmeras partes que estão ligadas entre si, formando um todo [...]". O que a gente considera engenhoso, na minha opinião. Que é justamente o que a nossa profissão se propõe a fazer.
A primeira chavinha que eu quero te ajudar a virar, dev júnior, é a de entender que código complicado vale menos do que código complexo. Código bom é o que nós dois conseguimos ler!
Abaixo eu vou descrever um pouco mais sobre o porquê de ser essencial você aprender a estilizar código desde já!
Estilizar o código te ajuda a pedir ajuda
Vamos partir de um pressuposto simples: "Hey, me ajuda!" é bem diferente de "Hey, faz pra mim?". Por isso o jeito certo de pedir ajuda é reduzir o problema ao máximo possível.
Uma das grandes fontes de confusão e dificuldade na hora de pedir ajuda, é localizar o problema. Vamos ver um exemplo?
/**
* Hey, me ajuda? O compilador diz que deu pau na linha 2
*/
1. ((function(){console.log( a + 1 / 100
2. );}
É somente natural que você não entenda onde está o problema. Eu mesmo não faço a menor ideia de o que tá acontecendo ali.
Com o código um pouco mais organizado talvez você nem precise pedir ajuda. Vamos isolar cada bloco em sua própria linha e ver o que aconteceu:
1. (
2. (
3. function () {
4. console.log(a + 1 / 100)
5. // ...
Depois da linha 5 ficou claro que faltaram alguns parênteses e chaves. Uma chave } para fechar o escopo da função, dois parênteses pra fechar a expressão das linhas 1 e 2.
Estilizar seu código vai te ajudar a entender o que VOCÊ está fazendo em primeiro lugar. E torna muito mais fácil para outras pessoas te ajudarem mais tarde.
Como dizia minha incrível mãe: casa simples não é desculpa pra ser suja. Eu espero que você adote isso como uma regra de etiqueta: pedir ajuda com um código porco e mal formatado é uma falta de respeito enorme. Sempre mantenha a casa limpa!
Espero que tenha ficado clara a importância de estilizar o seu código enquanto iniciante no mundo da programação. Agora vem comigo, que eu vou te explicar o que eu quero dizer com estilo de código.
O que é estilo de código
A metáfora da casa limpa se aplica muito bem aqui. No fim das contas você, e qualquer outra pessoa desenvolvedora, deveria ser capaz de navegar no código que escrevem com facilidade.
O estilo de código adota regras que afetam vários aspectos do seu software. Algumas destas regras são sobre:
- estilo de formatação;
- regras de indentação de código;
- regras para quebra de linha;
- limite de caracteres por linha;
- nomenclatura de variáveis, funções, classes e métodos;
- organização em pastas e nomes de arquivos;
- outras boas práticas
Não adianta apenas adotar um estilo de código. É importante ser consistente com aquele estilo.
Por exemplo, se você indentou um arquivo JavaScript com 2 espaços, o próximo arquivo não pode ser indentado com 4 espaços.
Para o computador, tanto faz se você usa 2 ou 4 espaços para indentar. Mas lembre-se: o computador é só mais um elemento na enorme lista de consumidores do seu código. Escreva código para pessoas, não para computadores!
Quebra de linha tá aí pra ser utilizada
Parece besteira, mas faz toda a diferença!
Gente, nós estamos em 2022! Uma quebra de linha custa o que? 2 bytes? Não tem motivo pra economizar linha, né.
Bora quebrar linha sem dó! Saiu um ponto e vírgula? Dá-lhe enter!
Bate o olho e me diz o que esse código faz:
const primeira = 10; const terceira = 20; const segunda = 30;
console.log(primeira, terceira, segunda, primeira * 2);
Agora bate o olho nesse aqui e me diz o que ele faz:
const primeira = 10;
const terceira = 20;
const segunda = 30;
console.log(
primeira,
terceira,
segunda,
primeira * 2
);
Faz sentido eu quebrar linha até mesmo dentro do console.log? No fim das contas fica mais fácil ler o que eu tô passando pra dentro da função.
A época dos monitores de 320x240 pixels já passou faz tempo, gente. Vamo sem meguelar quebra de linha!
Indentação de código
Indentação é quando a gente afasta o código da margem pra organizar. Quando se abre um bloco de código, normalmente é hora de indentar.
Aqui um código não indentado:
function euOdeioAMinhaVida() {
const motivo = 'Porque eu não indento código!';
if (motivo.length > 100) {
console.log('Mó filosofia do ódio')
}
else
{
console.log('E o motivo é simples:', motivo)
}
}Um código parecido, mas com indentação:
function euAmoAMinhaVida() {
const motivo = 'Porque eu indento código!';
if (motivo.length > 100) {
console.log('Olha que delícia essa indentação')
} else {
console.log('E o motivo é simples:', motivo)
}
}No bloco de código do corpo da função euAmoAMinhaVida() eu adicionei uma indentação. Lá dentro tem alguns IFs. Pro bloco de cada IF, eu adicionei mais uma indentação.
Tem gente que se importa sobre o seu código usar Tabulações ou Espaços para indentação. Tem gente que se importa ainda se ao indentar com espaços você usa 2, 4 ou 6 espaços...
Tanto faz!
O importante é indentar o código sempre e ser consistente com seu estilo de indentação. Se começou usando 2 espaços, continua com 2 espaços. E por favor não caia na besteira de indentar um arquivo com 2 espaços, outro com 4, outro com 6 e montar uma salada de indentação. Consistência!
Claro que a indentação por si só não é suficiente para escrever um código bom e que todo mundo vá entender. O Hadouken que o diga:
Ferramentas automatizadas
Daí você me pergunta: tá, mas como eu sei qual o jeito certo de estilizar o código? Tem de quebrar linha no lugar certo, tem de indentar do jeito certo... Onde eu acho isso tudo?
Cada linguagem de programação tem sua comunidade e suas convenções. Você precisa procurar entender a de cada linguagem com que pretende trabalhar.
Para a nossa sorte, existem ferramentas que controlam e dizem pra gente quando algo está errado. Algumas até corrigem o código pra gente!
No mundo JavaScript/TypeScript tem o tal do Eslint. No mundo PHP, tem o PHP Code Sniffer. O Rust tem o rustfmt e por aí vai.
O bom de usar uma ferramenta automatizada, é que você vai desenvolver a "memória muscular" de como escrever código sem precisar decorar milhares de regras pra cada linguagem.
Dica de ouro: sempre que fizer um coding challenge pra passar naquela entrevista, adicione um linter como o eslint ou phpcs. Vai te dar alguns pontos na avaliação 😉.
Escolha de nomes para variáveis e funções
O nome é importante, gente. Vamos combinar aqui: variável a, b ou c não faz o menor sentido a não ser que você esteja fazendo um programa pra solucionar equações de segundo grau! E eu não quero nem ver variável tmp, ein...
Todas as regras que se aplicam a nome de variáveis também se aplicam a classes, métodos e funções.
Vamos combinar três cláusulas pétreas aqui, tá?
- Não abrevie nomes:
fmtnão faz sentido NENHUM! Use o nome completo, não precisa economizar bytes em disco; - Sem nomes sequenciais:
line,line2,line3... Isso é coisa de maluque! Precisa de uma lista? Use uma lista e pronto! - Dê significado semântico pros seus nomes: o nome precisa fazer sentido no contexto em que está inserido. Deixa eu explicar um pouco melhor...
Eu já trabalhei numa empresa que dizia o seguinte: toda variável precisa ter um prefixo que indica o tipo dela. Uma variável var do tipo inteiro se chama iVar, do tipo boolean bVar, do tipo float fica fVar.
Gente, o ano é 2022! Sua IDE e ferramentas de análise estática já vão garantir o tipo de uma variável. Não tem motivo prefixar ou sufixar variável com tipo. Isso não adiciona nenhum sentido semântico.
Agora quer ver como a semântica muda a compreensão de código? Olha aqui:
if (number % 2 === 0) {
// ...
}O código acima faz exatamente a mesma coisa que este aqui:
const isNumberEven = number % 2 === 0
if (isNumberEven) {
// ...
}
Qual IF você entende com mais facilidade?
Pela semântica, vale tudo! Até criar variável "inútil". Estamos em 2022, você não precisa economizar bits e bytes. Criar uma variável a mais não vai comer sua memória RAM e de quebra vai economizar um tempão de quem lê seu código, inclusive você!
Como mecanizar estas práticas
E a coisa é esta mesmo: mecanizar. Você precisa adotar estas práticas automaticamente, quase sem pensar!
Aqui vão algumas dicas pra não se perder nas regras.
Feche blocos imediatamente depois de abrir
Já se deparou com a situação em que abriu um parêntese, e depois outro, e mais outro e mais outro, e acaba precisando contar parênteses pra saber onde fechar o que?
a + (b * c ( x + y + (d ^ 2)) + 10)
Sai dessa vida, gente... Ficar contando parêntese, pára com isso...
Abriu o parêntese? Fecha imediatamente e continua só depois! Abriu chaves? Fecha imediatamente e continua só depois! Seu código vai te exigir pular linha? Pula a linha primeiro e depois volta pra onde tava!
if () {
}Sabe esse IF aí em cima? Eu quero que você prometa pra mim que só vai escrever a condição dentro dos parênteses depois que tiver digitado o ).
Cuide primeiro da sintaxe, depois da semântica! Abriu parêntese, fecha imediatamente. Abriu chaves, fecha imediatamente.
A regra dos 80 caracteres
Se tu tiver usando uma tela grande pra ler este texto vai reparar que eu não deixo o texto usar a sua tela toda. Sabe o motivo? Porque tu não iria ler, simples assim.
Linhas longas não são lidas! Quanto maior a linha, menor a atenção que ela vai receber.
Uma regra comum é a de quebrar a linha depois de um limite. Algumas comunidades adotam 80 caracteres, outras 120. Adote um e seja feliz.
A maioria dos editores de código vão te ajudar com isso ao colocar uma linha vertical no meio na sua tela. Se o seu código encostar nesta linha, é hora de quebrar linha.
Agora, atenção ein! Não vai quebrar a linha como quem joga entulho no quintal do vizinho! Se você quebrar linha no contexto de elementos separados por vírgula, dê uma linha para cada elemento.
Não faça isso:
echo sprintf('Minha string %s formatada %d vezes', 'Nawarian',
10);Faça isso:
echo sprintf(
'Minha string %s formatada %d vezes',
'Nawarian',
10
);
E note que o parêntese que fecha a função sprintf está alinhado verticalmente com o começo da linha que abriu aquele parêntese. Além disso, os parâmetros, cada um em sua linha, estão indentados uma única vez.
Linhas grandes não são lidas, são feias que dói e deveriam te causar repulsa! Quebre a linha sempre que precisar e use uma regra padrão.
Escreva seu código duas vezes
No início da nossa carreira a gente costuma escrever código e se funcionar, funcionou! Segue o jogo.
Você precisa cortar este hábito o quanto antes!
Sempre que você terminar de escrever um código, volte ao começo e leia tudo de novo pra ver se tem algo que você pode deixar mais claro.
Lembre-se: você quer escrever código para outras pessoas lerem, não só para o computador ler.
Uma quebra de linha, um nome de variável melhor, uma modificação na lógica... tudo isso pode ajudar bastante.
Vou te dar um exemplo. Olha o seguinte snippet de um emulador que eu escrevi:
function readZeroPage(): int
{
return $this->bus->read($this->state->pc++) & 0xFF;
}
Sim, estou escrevendo um emulador de Nintendinho 8-bit. Dá uma olhada no meu Devlog sobre como criar um emulador de NES pra aprender como fazer o seu.
O exemplo acima está bem simplificado pra quem entende o domínio. Mas se eu quiser simplificar para que todo mundo possa entender com menos dificuldade, poderia ter algo assim:
function readZeroPage(): int
{
$address = getProgramCounterAddress();
incrementProgramCounter();
$zeroPageValue = $this->bus->read($address);
return asInt8($zeroPageValue);
}
O que é um código bom ou legível é totalmente subjetivo e depende não só de quem lê, mas também do contexto. No caso do desenvolvimento de um emulador de CPU os conceitos de pc, bus, zero page e int8 são bem comuns. Mas é inegável que o segundo exemplo de código explica muito mais sobre o que está acontecendo do que o primeiro.
Depois de escrever seu código - seja uma página, uma função ou um mesmo um IF - releia tudo para identificar se você pode tornar o contexto mais explícito e comunicar a sua intenção com código.
Não escreva código como é ensinado em cursos e faculdades
Existe um problema muito comum com iniciantes que acabaram de ver um curso ou estão na faculdade. O código das pessoas nessa fase normalmente é BEM RUIM de entender.
Isto porque nos cursos nós ensinamos conceitos, métodos e técnicas. O estilo de código fica secundário e dá mais trabalho de ensinar ao mesmo tempo.
Especialmente em faculdades, professores mais velhos - com todo o respeito, nós devemos a modernidade a estes profissionais - adotam costumes que eram comuns há algumas décadas atrás, quando precisávamos economizar espaço a todo custo e conseguíamos parar em frente a um texto por mais de 1 hora sem receber uma notificação de que alguém está tretando no Twitter!
Boa parte das práticas que são adotadas durante cursos (alô variável temp!) precisam ser extintas do seu vocabulário! Absorva o conteúdo, não o estilo!
E pra deixar claro, o problema não são os professores mais velhos. O problema é que professores normalmente não escrevem código profissionalmente há alguns bons anos.
Adote o estilo de profissionais que trabalham com desenvolvimento software, não ensinando desenvolvimento de software. São duas profissões distintas!
O mais importante te tudo: leia código de pessoas mais experientes
Fica claro que se você não pode confiar no código de quem te ensina código, precisamos buscar inspiração noutro lugar.
Como eu disse antes, cada linguagem tem as suas comunidades, convenções e estilos. Cabe a você aprender os estilos que lhe interessam.
Aqui vão algumas dicas de como achar essa inspiração.
Navegue no Github em busca de Pull Requests
Pull Requests são incríveis fontes de conhecimento sobre como as outras pessoas escrevem código.
Olha este exemplo do repositório aberto do Monolog. Você consegue ver quais arquivos foram modificados, onde e como. Além disso, os responsáveis pelo repositório adicionam comentários e perguntas sobre o código.
Uma das melhores formas de aprender como escrever código de acordo com o estilo da sua comunidade, é lendo pull requests enviados para esta comunidade.
Mais efetivo ainda é você enviar um pull request e receber comentários de volta. A comunidade ganha, você ganha, todo mundo ganha!
Navegue nos repositórios da sua empresa
No contexto de uma empresa, o melhor é ver como as outras pessoas já operam.
Normalmente se a empresa é moderna no quesito desenvolvimento de software, esta será uma fonte incrível. Mas se você duvida da qualidade do código e das pessoas que o produzem, ignore esta dica - e procure outro emprego o quanto antes.
Participe, mesmo que como ouvinte, de discussões sobre estilização de código
O que eu disse lá no começo é muito verdade. Tudo depende, e muitas pessoas desenvolvedoras gostam de discutir de fundamentos a nuances sobre estilo de código.
Participe destas discussões o quanto puder: em reuniões, em conferências, em fóruns, no Twitter... Não importa se você estiver errade! Se alguém te corrigir você terá aprendido. Mas o mais importante é ver outras pessoas trocando conhecimento e opiniões também.
Voa, juninhe! Voa!
É claro que eu escrevi este artigo num tom mais energético e duro, mas a intenção não é te desmotivar.
Eu quero que estilo de código seja algo natural pra ti, e que você incorpore estas dicas no seu dia a dia de forma automática pra que possa focar na lógica que está aprendendo, em vez de se preocupar com bobeiras de estilo.
Se a estilização for tarefa mecânica pra ti, vão te ficar disponíveis muito mais neurônios pra focar no que importa: resolver o seu problema de código.
Vai que a sua jornada tá só começando e o futuro é próspero! Voa, juninhe! Voa!
Compartilha este texto com a galera pra ajudar e trazer pra discussão, belezera? Te vejo na próxima.
Comentários