Naming Standard¶
Objetivo¶
Definir o padrão oficial de nomenclatura de código para os produtos do ambiente hauxtech.
Idioma dos nomes¶
Padrão vigente (desde a skill com-padronizar-nomenclatura-pt-br)¶
Todo model novo e todo campo novo criado em qualquer app do ambiente hauxtech deve usar nomes em Português (Brasil).
class Oportunidade(BaseModel):
responsavel = models.ForeignKey(User, on_delete=models.PROTECT)
valor_estimado = models.DecimalField(max_digits=12, decimal_places=2)
data_fechamento = models.DateField(null=True, blank=True)
Esta é a regra para código novo. Ela não é aplicada retroativamente a apps já existentes — ver exceções reais abaixo.
Exceções reais observadas (não corrigir sem pedido explícito)¶
O código real dos produtos hauxtech é anterior, em parte, a essa decisão, e por isso está misto. Exemplo confirmado no CoreFlow CRM (apps/accounts/models.py, apps/core/models.py):
| App (PT-BR) | Classes (EN, legado) |
|---|---|
accounts |
User, Role |
core |
BaseModel |
auditoria |
AuditLog |
A regra 08 do padrão de codificação (nunca gerar migração para model já existente) se aplica aqui: não renomear classes/campos de apps em produção só para "corrigir" o idioma — a padronização vale para o que é criado dali para frente.
Convenções gerais (independentes de idioma)¶
Classes (models, services, views baseadas em classe)¶
PascalCase
Funções, métodos e variáveis¶
snake_case
Apps Django¶
snake_case, no singular ou plural conforme o domínio já em uso no produto (ver exceções reais — não misturar convenção dentro do mesmo produto).
Templates e arquivos estáticos¶
kebab-case
Rotas de API¶
Sempre sob o prefixo de versão:
Branches e commits¶
Ver Git Standard.
Objetivo Final¶
Nomes de código devem ser autoexplicativos para quem lê o domínio de negócio em português — sem exigir tradução mental entre o termo usado no sistema e o termo usado pela equipe e pelos usuários finais.