Seja consistente no seu código!

Pode parecer preciosismo, mas manter seu código consistente deveria ser uma coisa relevante pra você. Não falo apenas de estrutura e técnicas de abordagem ou arquitetura. Tô falando do básico mesmo! Espaços, indentação, limitadores de blocos, pontuação e até aquele “enter” muitas vezes ignorado.

Praticamente todo código hoje em dia tem versionamento e no futuro é muito provável que você precise consultar o histórico de alterações para saber como resolveu um problema ou formatou aquele “CSS do demo”. Além disso, projetos maiores envolvem várias pessoas que também podem querer consultar esse histórico para entender melhor esse código.

Exemplo 1

Aparentemente, entre as duas versões do código abaixo, eu só mudei a linha 5.

1
2
3
4
5
6
7
8
9

{{ define "main" }}
    <article>
		<h2>{{ .Title }}</h2>
		{{ with .Date }}   
		<p>Publicado em 02 de janeiro de 2006</p>
		{{ end }}
		{{ .Content }}
	</article>
{{ end }}

versão original

1
2
3
4
5
6
7
8
9

{{ define "main" }}
	<article>
		<h2>{{ .Title }}</h2>
		{{ with .Date }}
		<p>Publicado em 2/1/2006</p>
		{{ end }}
		{{ .Content }}
	</article>
{{ end }}

Versão alterada

Na hora do diff…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

2c2
<     <article>
---
>       <article>
4,5c4,5
<               {{ with .Date }}   
<               <p>Publicado em 02 de janeiro de 2006</p>
---
>               {{ with .Date }}
>               <p>Publicado em 2/1/2006</p>
9c9
< {{ end }}
\ No newline at end of file
---
> {{ end }}

Saída poluída…

1
2
3
4

5c5
<               <p>Publicado em 02 de janeiro de 2006</p>
---
>               <p>Publicado em 2/1/2006</p>

…como deveria ser

A “pegadinha” está em tabs trocados por “espaços”, um enter a mais de um lado, um “espaço” esquecido num final de linha… Não é só o código que precisa ser legível. Um diff resumido pode facilitar mais o entendimento do que a própria mensagem do commit. Isso pode confundir até mesmo quem fez o código, quando se passarem uns dias.

Exemplo 2

Considere o código Javascript abaixo:

1
2
3
4

const obj = {
    nome: 'Hítalo',
    sobrenome: 'Silva',
}

Aquela vírgula no final da linha em destaque não faz diferença para o JS, mas se for preciso adicionar mais propriedades ao objeto no futuro, a inserção dessa vírgula vai fazer essa linha também aparecer no diff. Sei que parece preciosismo exagerado, mas e se o seu editor já adiantar esse cuidado pra você?!

Uma curiosidade do git, é que ele considera aquele “enter” no final de uma linha. Então se você não terminar um arquivo com uma linha em branco e depois precisar adicionar mais código ao final, aquela linha que era a última vai aparecer no diff também, do mesmo jeito do exemplo da vírgula.

Formatadores

Algumas linguagens tem formatadores que seguem um conjunto de regras para deixar seu código mais consistente. Muitas deixam você escolher que regras quer ignorar ou sair um pouco do padrão (Ex.: trocar tabs por espaços). No caso da linguagem Go, o formatador padrão é totalmente “determinístico”, acho nem dá pra customizar as regras. Isso pode parecer chato, principalmente se você costuma seguir um outro padrão, mas gera uma consistência “universal”. Qualquer código Go fica muito parecido e quando você se acostuma, também fica mais fácil de ler. Em tempo, na comunidade Go, tal formatação não é obrigatória, mas provavelmente você será xingado se não usá-la.

Um bom começo é usar um ou vários plugins no seu editor de código que façam pequenas correções. Há plugins que apontam coisas simples como espaços duplicados ou desnecessários, um “snake_case” onde deveria estar sendo usado “camelCase” ou um nome de variável muito curto para o escopo em que ela é referenciada e por aí vai!

O primeiro plugin que eu indico é o editorconfig. Quase todo editor de código tem plugin para ele, basta criar um arquivo de configuração na raiz do seu projeto e qualquer editor que use o plugin vai entender algumas regras básicas. Assim, você e outras pessoas em máquinas diferentes, usando editores diferentes, já conseguem ter menos divergências. Independente das configurações pessoais ou que já venham no editor, assim você personaliza por projeto.

Linters

Algumas comunidades de linguagens tem ferramentas chamadas “linters” que analisam seu código e sugerem possíveis alterações. As melhores chegam até a alertar quando a bugs ou possíveis problemas de segurança.

No mundo do Javascript por exemplo, dois dos mais conhecidos são o eslint e o prettier. Os dois também tem plugins e/ou extensões para reconhecer outras linguagens, mas provavelmente a sua linguagem preferida já deve ter um formatador padrão ou mais indicado. Esses caras podem varrer todo o código do projeto e fazer as mudanças necessárias de modo que não “quebre” ou mude o que o seu código já fazia. Para projetos em Go, eu sugiro o golangci-lint.

Avançando um pouco mais…

Para automatizar e garantir que você não faça commits sem antes revisar seu código, pode-se configurar scripts nos hooks do git e mais além, num CI do projeto.

Concluindo…

O fato de pessoas diferentes, usando editores diferentes, convergirem para um padrão, vai diminuir muito a poluição de código quando for preciso analisar o histórico de mudanças do seu projeto. Isso tanto facilita a manutenção quanto a “ambientação” de quem for chegando pra contribuir. Considere também que você, daqui a 6 meses, poderá ficar confuso com algumas coisas (falo por experiência). Uma vez “afinando” essas configurações para um primeiro projeto, fica muito fácil e até viciante usar sempre esse tipo de abordagem nor próximos.

Vejam que eu nem cheguei a falar dos medonhos “testes”!