5
respostas

Qual a convenção para nomear os arquivos?

1)Na pasta "controller" devemos chamar os arquivos de "PessoaController", com a primeira letra maiúscula por causa que o arquivo vai ter uma classe com esse nome ou devemos chamar de "pessoaController" ou "pessoasController"?
2)Na pasta "routes" devemos chamar os arquivos de "pessoasRoute", "pessoaRoute" ou "pessoasRoutes"? E a letra maiúscula na primeira letra?
3)Na pasta "services" devemos chamar os arquivos de "pessoaService", "pessoaServices" ou "pessoasServices"? E a letra maiúscula na primeira letra?
Tem alguma convenção que se usa?

Matricule-se agora e aproveite até 50% OFF

O maior desconto do ano para você evoluir com a maior escola de tecnologia

QUERO APROVEITAR
5 respostas

Olá, Luidi! Tudo bem?

Essa é uma dúvida comum quando estamos organizando nossos projetos, e seguir uma convenção pode ajudar a manter o código mais legível e padronizado. Vamos lá:

  1. Na pasta "controller": É comum nomear os arquivos de controladores com a primeira letra maiúscula, como "PessoaController.js". Isso porque geralmente eles contêm classes, e em JavaScript, é uma prática comum nomear classes com PascalCase (primeira letra de cada palavra em maiúscula).

  2. Na pasta "routes": Os arquivos de rotas geralmente são nomeados em camelCase, como "pessoasRoute.js" ou "pessoaRoute.js". O uso do plural ou singular depende de como você está estruturando suas rotas. Se cada arquivo de rota lida com múltiplas entidades (como várias pessoas), "pessoasRoute.js" pode fazer mais sentido.

  3. Na pasta "services": Assim como os controladores, os serviços muitas vezes são nomeados em camelCase, como "pessoaService.js". Novamente, o uso do singular ou plural pode depender do conteúdo do arquivo. Se o serviço gerencia várias entidades, "pessoasService.js" pode ser apropriado.

Não existe uma convenção única que todos seguem, mas o importante é ser consistente dentro do seu projeto. Escolha um padrão que faça sentido para você e sua equipe e siga-o em todo o projeto.

Espero ter ajudado e bons estudos!

Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.

Não entendi muito bem no caso da pasta "routes" e "services". Tu poderia me dar um exemplo de cada pasta de quando usar no singular e plural?

Bom dia, Luidi! Claro que posso!

Vamos detalhar esse ponto — o uso de singular ou plural em nomes de arquivos (como pessoaRoute.js ou pessoasRoute.js) está ligado à intenção semântica e à organização lógica do código.

Na pasta routes/

O nome do arquivo costuma refletir o recurso da API que ele manipula.

Plural (pessoasRoute.js)

Usado quando o arquivo define rotas que manipulam coleções de entidades:

GET /pessoas        // lista todas as pessoas
POST /pessoas       // cria uma nova pessoa
GET /pessoas/:id    // obtém uma pessoa específica

Nesse caso, faz sentido usar o plural porque o endpoint principal se refere a um conjunto de pessoas.

Singular (pessoaRoute.js)

Mais raro, mas pode aparecer quando o arquivo se dedica a uma entidade individual ou a um contexto específico:

GET /pessoa/:id     // obtém uma pessoa específica
PUT /pessoa/:id     // atualiza uma pessoa específica

Aqui, o foco está em uma instância única do recurso.

Em APIs REST, o plural é mais comum e consistente com boas práticas, já que normalmente tratamos coleções de recursos.

Na pasta services/

Os serviços contêm a lógica de negócio — as operações sobre os dados.
A escolha entre singular e plural depende da abstração que você quer transmitir.

Singular (pessoaService.js)

Usado quando o serviço representa a lógica de um único tipo de entidade:

// pessoaService.js
export function criarPessoa(dados) { ... }
export function buscarPessoaPorId(id) { ... }

Aqui, o foco está nas operações de uma pessoa, mesmo que o código lide com várias internamente.

Plural (pessoasService.js)

Usado quando o serviço manipula várias entidades de maneira mais genérica:

// pessoasService.js
export function listarPessoas() { ... }
export function removerPessoasInativas() { ... }

Indica que o serviço trabalha com coleções, não com uma entidade isolada.

Mas pensando em fora do contexto do JavaScript, em Java normalmente usamos o singular, por ser o mais comum em projetos em inglês, sendo como uma conversão direta para o português. Resumindo tudo, fica a seu critério ter essa intensão semântica usando o plural ou seguir um conversão simples do singular.

No mais, fico à disposição!

Acho q entendi quase tudo, só não entendi essa parte:
Insira aqui a descrição dessa imagem para ajudar na acessibilidade

Tu está chamando de "entidade", uma instância na verdade né? Não, por exemplo, "pessoa", "curso", "matricula", etc, que seriam considerados "entidades", né? E a parte que diz "mesmo que o código lide com várias internamente" eu não entendi, pois se estiver lidando com mais de uma instância de pessoa, o ideal não seria trocar o nome do arquivo para o plural?

Oi, Luidi!

Ótima observação — "entidade" e "instância" realmente têm significados diferentes nesse contexto.
Quando mencionei entidade, estou falando do conceito representado no domínio da aplicação, por exemplo: Pessoa, Curso, Matrícula.
Esses são modelos conceituais, geralmente refletidos nas classes do ORM (como Pessoa.js) ou nas tabelas do banco de dados.

instância é um objeto específico de uma entidade — ou seja, um registro individual.
Por exemplo, pessoa = { id: 1, nome: 'Luidi' } é uma instância da entidade Pessoa.

Então, o arquivo pessoaService.js representa o serviço responsável por lidar com a entidade Pessoa, e não com uma instância específica.
Mesmo que internamente ele trate de várias instâncias (por exemplo, buscar várias pessoas no banco), o nome permanece no singular, porque o foco é a entidade Pessoa, não o conjunto em si.

Veja este exemplo:


// pessoaService.js
export function listarPessoas() { ... }
export function criarPessoa(dados) { ... }
export function buscarPessoaPorId(id) { ... }

Note que, mesmo manipulando muitas pessoas, o nome do arquivo continua singular porque ele centraliza as regras da entidade Pessoa.
O plural só seria realmente indicado se o módulo representasse um conjunto mais genérico, como pessoasService.js sendo responsável por diversas entidades ou coleções diferentes — o que é bem raro.

Fico à disposição.