Skip to main content

Command Palette

Search for a command to run...

Angular Coding Style Guide: Part 3 (Naming)🚀

Published
Angular Coding Style Guide: Part 3 (Naming)🚀
R

Hi, I'm Rafael, but you can call me Rafa! 😄 I'm a software engineer passionate about everything that involves technology, with more than 5 years of experience in the market. Throughout my career, I worked in banking institutions, developing innovative solutions and contributing to the digital transformation of the financial sector.

With a strong interest in software architecture and testing, I am constantly looking to specialize and improve my skills in this area.

Here, you will find tips, tutorials and discussions on the most varied topics related to architecture, good practices and software testing, always with the aim of sharing knowledge and learning from other developers. I value the exchange of experiences and I am always willing to listen and learn from my professional colleagues.

Feel free to get in contact, leave your comments and share your own experiences and knowledge. Together, we can build a stronger, more collaborative community in the software development world.

Introdução

Definir um padrão para nomear os componentes que vamos utilizar no Angular é essencial para ter um projeto organizado. O style guide recomenda convenções de nomenclatura para o nome do arquivo e o nome do símbolo. Vamos aprender com o guia como seguir as recomendações.

Nomes

Precisamos sempre usar nomes consistentes para os nossos arquivos. Seguir um padrão que descreva a característica do arquivo e então seu tipo (service, pipe, model, guard e assim por diante).

Vamos supor que seja preciso criar um componente, que cuidará de determinadas funções relacionadas a produtos, a nomenclatura que a documentação pede é essa, products-create.component.ts. Assim fica claro que esse componente pertence ao módulo de produtos, e que a responsabilidade dele é criar. O style guide dá um exemplo parecido, feature.type.ts.

Mas por que é bom seguir esse padrão? É uma boa prática já que as convenções de nomenclatura ajudam a fornecer uma maneira consistente de localizar no projeto rapidamente os arquivos que vamos trabalhar. Trazer agilidade para dentro do projeto é essencial, ninguém gosta de gastar tempo procurando arquivos que poderiam estar nomeados corretamente. Mas é importante que todos os envolvidos no projeto façam isso, assim o padrão é mantido por todos e não por apenas um desenvolvedor.

Além de tudo isso, os nomes das pastas e arquivos devem transmitir claramente sua intenção. Veja este exemplo:

 app / products/ products-list.component.ts

Fica claro o que esse componente está responsável por listar todos os produtos.

Separando os nomes com pontos e hífen e definindo os seus tipos

É importante separar os nomes com hífen, como por exemplo:

products-list.component.ts
products-create.component.ts
product-update.component.ts

O tipo dele, se é uma service, pipe, guard, devemos separar por ponto:

products.guard.ts
products.service.ts
products.module.ts

Fazer isso fornece uma maneira fácil de identificar rapidamente o que está no arquivo. Comunicação com a API, rotas, módulos entre outros.

E se sempre evite abreviar, nomes de tipo não abreviados, como .service, são descritivos e não indeterminados. Abreviações como .srv, .svc e .serv confundem.

Além disso outra recomendação é seguir essa nomenclatura:

@Component({ ... })                        // File name
export class AppComponent { }      =>    app.component.ts

Notem que temos em caixa alta o AppComponent com a primeira letra da palavra e segunda, é um padrão importante para adotarmos em nossos projetos no Angular, vejam que o nome da class corresponde ao nome do nosso arquivo app.component.ts.

Seguir esses padrões as vezes pode parecer chato, mas é essencial para a organização da nossa aplicação. Uma aplicação confusa com arquivos espalhados em pastas diferentes se um nome claro, sem saber o tipo de arquivo que estamos lidando, dificulta o trabalho de qualquer desenvolvedor. A organização é fundamental!

Fico por aqui neste post, qualquer dica será bem vinda, até a próxima! 😉

Referencias: https://angular.io/guide/styleguide#naming