🚀 Boas práticas ao nomear enums e interfaces no TypeScript

Manter um padrão consistente ao nomear enums e interfaces é essencial para a legibilidade e manutenção do código. Hoje vou compartilhar como eu organizo isso nos meus projetos e por que essas boas práticas fazem a diferença.

❌ O que evitar?

Aqui estão alguns problemas comuns ao definir enums e interfaces de forma inconsistente:

Enum e valores não seguem um padrão claro.
Mistura de idiomas (português + inglês).
Interface sem um padrão de herança bem definido.

Um exemplo ruim:

export enum StatusUsuario {
  ativo = 'ativo',
  inativo = 'inativo',
  bloqueado = 'bloqueado',
  pendente = 'pendente',
}

📌 Problemas neste código:

O nome do enum está em português, mas poderia estar em inglês para padronização.
Os valores do enum estão em minúsculas, dificultando a diferenciação entre constantes e variáveis.
Não há um padrão claro na nomeação.

✅ O que fazer?

Aqui está um exemplo de como eu organizo meus enums e interfaces no TypeScript:

export enum eUserStatus {
  ACTIVE = 'active',
  INACTIVE = 'inactive',
  BLOCKED = 'blocked',
  PENDING = 'pending',
}

export interface iUser extends iBase {
  name: string;
  email: string;
  password: string;
  status: eUserStatus;
}

🔥 Boas práticas aplicadas:

Prefixo e para indicar que se trata de um enum.
Prefixo i para identificar uma interface.
Uso de UPPER_CASE nos valores do enum, melhorando a leitura.
Consistência no idioma (tudo em inglês, sem mistura).
Interface iUser estendendo iBase, promovendo reuso de código.
status tipado com eUserStatus, evitando valores string soltos no código.

💡 É assim que eu organizo meus enums e interfaces!

Amanhã vou falar mais sobre esse assunto no vídeo do meu canal, onde explico como organizar e estruturar um projeto em Angular. 👀🔥

Sei que pode parecer estranho no início, mas depois a gente acostuma

Boas práticas? Será mesmo?

Usar prefixos para interfaces é um padrão adotado na comunidade do C# que nunca entendi a motivação. Justificar que é para identificar não me faz sentido, imagina usar C para identificar classes, CA para classes abstratas, O para objetos, S para identificar strings, DT para datas, A para arrays e por aí em diante, fica parencendo notação húngara.

A galera do Angular importou diversas práticas da comunidade C#, por isso é comum ver pessoas usarem essas convenções também.

Olhe o código abaixo, precisa de I para saber que DocumentExporter é uma interface? Acredito que não, o uso já dá legibilidade suficiente.

export class PDFExporter implements DocumentExporter {
  
  async export(originPath: string, destinationPath: string): Promise<void> {
      // ...
  }
}

export class XLSXExporter implements DocumentExporter {
  
  async export(originPath: string, destinationPath: string): Promise<void> {
      // ...
  }
}

Em tempos em que as IDEs e editores eram rústicos e limitados, até poderia ter alguma justificativa a para usar esse tipo de indicador. Mas hoje em dia você poderia chamar de uma convenção, não acho que possa classificar como boa prática.