“Não está bagunçado, só está arrumado do meu jeito”.

Quantas pessoas já ouviram ou deram essa desculpa acima achando que o outro realmente iria acreditar? Em se tratando do quarto ou da mesa de trabalho de alguém, essa frase até pode ser verdade, mas não no código em que várias pessoas podem mexer!

Para um programador, seu código-fonte é valioso, e para a empresa que ele trabalha é mais valioso ainda. Mas o valor de um código não se relaciona unicamente com o produto e a solução que ele pode gerar. Ele permeia todo o raciocínio e a complexidade técnica que levou ao seu funcionamento e à sua qualidade. E é justamente por causa dessa complexidade que sua legibilidade deve ser possível para todos.

É claro que as linguagens de programação não são todas iguais, mas dentro da mesma linguagem muitos padrões e boas práticas podem ser seguidas tornando a possibilidade de compreender o código comum para todos que saibam o mínimo de sua sintaxe. E muitas vezes, esses padrões de linguagens distintas podem até aproximá-las de uma versão mais comum a todas.

Muitas pessoas podem pegar um livro de física avançada e acabar não entendo seu conteúdo, mas se o idioma for conhecido e a disposição dos seus termos e de sua forma de escrita estiver de uma maneira legível para o leitor, todos podem entender sobre o que se trata seu assunto.

Padronização no código

Algumas empresas de tecnologia de grande porte como o Google e Airbnb divulgam manuais de boas práticas e padrões conhecidos como style guides com a finalidade de disseminar o estilo de codificação comprovado como eficaz dentro de seus times e seu processo de desenvolvimento.

Se relacionando sempre com o conceito lógico e básico de clean code, que guia e aconselha a organização básica que se deve ter internamente em um projeto de software, esses style guides vão desde a nomenclatura de métodos e variáveis até o espaçamento e a indentação do código (sim, essa é a forma certa de escrever para
esse significado).

Seja o time de desenvolvimento específico para uma certa linguagem ou híbrido, com cada membro cuidando de uma linguagem a parte, cada linguagem de programação trabalhada por ele possui seu conjunto de boas práticas de sintaxe e performance, mas todas elas podem ter sua própria forma customizada de desenvolvimento dentro da instituição sem nenhum problema. Afinal, foi assim que nasceram os style guides existentes hoje.

Qualquer equipe pode montar sua melhor forma de codificação e entrega, definido, por exemplo, seu próprio estilo de espaçamentos na linguagem JavaScript, sua própria forma de tratamento de erros no C#, e até a melhor maneira de representar os zeros e uns no código binário (tem louco pra tudo).

O que deve ser cuidadosamente analisado pela equipe em um nível estratégico e de gestão é a estabilidade que pode ser afetada durante o processo de produção com a tecnologia, e a adaptabilidade dos que já estão envolvidos no projeto e dos que ainda não estão, medindo a curva de aprendizado necessária para se acostumar com o
método de codificação e entrega.

Pode ser definido um determinado prefixo nas variáveis e componentes de uma linguagem de programação de uma equipe de desenvolvimento, por exemplo, mas juntamente dessa definição deve ser apontada e avaliada a facilidade de legibilidade desse recurso pelos integrantes atuais e pelos próximos.

Afinal, infelizmente para muitas equipes, os desenvolvedores que fazem parte dela hoje podem não fazer parte amanhã, seja por qualificação, novas oportunidades ou mesmo por causa de férias.

“Nem vou mexer porque pode ser que eu não entenda o código dele”

Essa citação acima é uma das piores frases que podem ser ouvidas no ramo de desenvolvimento em equipes, principalmente em um momento de emergência em um projeto. Para uma equipe conseguir manter a continuidade dos projetos, é preciso que não só a forma de deixar o código escrito no arquivo fonte seja padronizada e fácil de ser entendia, mas que também sua própria forma de raciocinar e trabalhar seja condizente com uma maneira compreensível por todos.

Não se trata de moldar a mente dos integrantes para pensar de uma só forma, mas de aproveitar a maneira inovadora e particular de cada um de uma forma lógica e natural de ser transmitida aos outros fazendo os style guides mais que simples regras impressas de como o código deve ficar, tornando-os realmente um guia de como a
cultura de pensamento do integrante e do time como um todo deve ser durante o desenvolvimento para todos atingirem o objetivo comum sempre que necessário, independentemente de quem entre ou saia ou de como certa pessoa deixou o código que outra poderá mexer.