Padrões de Código

És dos programadores que pensa que ter o código codificado numa espécie de cifra, a qual só tu entendes, para que ninguém te possa roubar o teu código, ou para que mais dificilmente te possam substituir numa equipa?

Espero que leias o artigo até ao fim pois tenho para ti algumas más notícias.

Aos restantes, leiam também que irão encontrar valor certamente.

A comunidade WordPress tem como slogan “code is poetry (código é poesia)“. Eu prefiro idealizar o código como uma boa prosa, escrita com atenção, com boas regras de pontuação e sem segundos sentidos. Basicamente, respeitando as máximas do “clean code (código limpo)“.

Padrão (substantivo masculino), o que serve de modelo ou referência.

Segundo a definição, tudo o que possa servir de modelo ou referência que permita consistência pode ser considerado um padrão. Assim, um padrão de código poderá ser somente um guia de estilo (coding style); como poderão ser fórmulas de resolver determinados problemas, designados por padrões de desenho (design patterns).

A utilização deste tipo de regras permite uma maior legibilidade do código. Ou seja, mais facilmente o código poderá ser lido e entendido por outras pessoas. Ao contrário da premissa do início do artigo, a existência de mais “olhos” sobre o código aumentará substancialmente a detecção de possíveis falhas de performance ou segurança. Com isto também se irá diminuir o sentimento de único proprietário do código, permitindo uma mais fácil partilha de conhecimento entre toda a equipa. Não, não te vão roubar o lugar…na realidade, terás mais oportunidades de evoluir enquanto programador, e isso sim, te fará manter na profissão que escolheste durante mais tempo.

(Fonte: Rose-Hulman – Institute of Technology)

Os padrões de desenho já existem há considerável tempo, existindo uma “bíblia” escrita pelo gangue dos 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

No entanto, com este artigo pretendo me focar mais sobre os guias de estilo.

Diariamente, na log, utilizamos PHP e WordPress, JavaScript, CSS e HTML. Penso que todas as linguagens de programação terão algum tipo de guia de estilo.

Para PHP existe um projecto designado por “PHP Framework Interop Group” onde se debatem e decidem quais os padrões que deverão vigorar. As recomendações para guias de estilo são o PSR-1 (Basic Coding Standard) e o PSR-2 (Coding Style Guide). Existe uma proposta, ainda em estado de rascunho, para um guia de estilo alargado (PSR-12).

O WordPress, apesar do seu código-base ser PHP, sugere um guia de estilo diferente – WordPress Coding Standards – que contradiz alguns pontos do PSR-2. Se pretendes desenvolver plugins, temas ou participar na evolução do core do WordPress, então terás de respeitar o seu guia de estilo.

Na nossa equipa respeitamos o guia de estilo do WordPress, e adicionamos mais algumas regras. Podes ler, usar e contribuir no nosso github.

Muitas vezes, se não a maioria das vezes, este tipo de iniciativas nasce dentro de empresas que não estão directamente associadas à evolução da linguagem ou framework (ou CMS). Um bom exemplo disso é o guia de estilos para JavaScript escrito pela empresa airbnb. Uma das vantagens do código-livre, o projecto poder nascer dentro de uma empresa e passar a ser do Mundo quando existem mais pessoas externas a participar na manutenção e evolução do mesmo.

Para CSS existem várias metodologias como o BEM (Block Element Modifier) que nós utilizamos na log.

No fundo não interessa se vais adoptar o guia de estilo A ou B, mas sim se algum será adoptado dentro da tua equipa. Esse é o desafio maior e onde se sentirão os maiores benefícios. O sentimento de propriedade partilhado por toda a tua equipa fará aumentar a qualidade do código por vocês escrito. Melhor qualidade de código, menor o número de bugs reportados. Melhor código facilitará a sua manutenção. Melhor código permitirá um sistema mais estável e mais maduro. Terás orgulho em ter escrito parte de um bom sistema, assim como o teu empregador.

Como vês, os beneficios serão de toda a equipa, e de ti também.

Deixe uma resposta