Existe uma piada nerd, daquelas bem de nicho, que elenca as três coisas mais difíceis na ciência da computação: Definir o TTL (Time-To-Live) para invalidação de cache, nomear as coisas e saber se um array começa em 0 ou 1. Ok, a piada pode ser “sem graça” para alguns, mas ela toca em uma verdade profunda do nosso dia a dia. Neste post, vamos mergulhar na segunda dificuldade: o desafio de dar nomes significativos e consistentes a variáveis, recursos e componentes de software.

No desenvolvimento moderno, especialmente na criação de automações e arquiteturas de microsserviços, lidamos com um ecossistema complexo: múltiplas ferramentas, cada uma com suas convenções, e variáveis que transitam por diversos scripts, ambientes e sistemas. A falta de padronização se transforma rapidamente em débito técnico e confusão operacional.Considere o seguinte cenário de exemplo para um novo Content Management System (CMS):

• 08 repositórios
• 08 micro serviços
• 08 builds
• 02 bancos de dados
• 05 filas de mensagens
• 01 API Gateway externo
• 03 ambientes de implantação: DEV, QA, PROD

Vamos fazer uma conta rápida do mínimo de itens únicos que precisam de um nome/identificador (e serão replicados pelos ambientes):

$$ (( 08 micro serviços + 02 Bancos de dados + 05 Filas + 01 API gateway ) \times 3 Ambientes) + 08 Repos* + 08 builds* ) $$ $$ (( 8 + 2 + 5 + 1) ×3) + 8 + 8 $$ $$ 48+8+8 = 64 $$

(*) Repos e nomes dos artefatos de builds não se repetem, neste caso simplificado.

Estamos falando de 64 nomes únicos minimamente, e isso sem contar variáveis de ambiente para armazenar senhas, chaves e outros artefatos que também precisam de uma nomenclatura consistente, consegue perceber o valor da padronização? Já parou para pensar em quanto o seu trabalho seria mais simples se tudo seguisse um modelo consistente?

Ter padrões não é burocracia é sobre eficiência e clareza. Sem isso, os problemas aparecem na gestão da evolução do projeto nos seguintes momentos:

• Debug vira arqueologia de código Você perde horas procurando uma variável chamada nomeServidor_v2 em um ambiente e servidor-nome-prod em outro. O que deveria ser um debug rápido vira uma escavação em busca de lógica perdida.

• Risco de erro aumenta Quando cada pessoa adota sua própria convenção, a chance de erro de digitação ou de referência incorreta durante um deploy cresce exponencialmente. É o tipo de falha que ninguém quer descobrir em produção.

• Produtividade despenca e colaboração evapora Sem um padrão, os projetos viram “feudos” onde só o autor entende o que está acontecendo. Um novo membro da equipe leva dias — às vezes semanas — para entender a estrutura do código.

• Manutenção se torna um pesadelo O que deveria ser um código de IaC limpo e reutilizável vira um labirinto de scripts quebrados e nomes confusos. Cada nova feature exige refatorações caras e demoradas.

Sem padronização, não há escalabilidade, se queremos pipelines robustos, código legível e colaboração real, precisamos de padrões especialmente naquilo que parece mais banal a nomenclatura. Definir convenções claras para nomes de variáveis, recursos, arquivos e estágios de pipeline transforma um amontoado de scripts em um sistema coeso, previsível e idempotente. No fim, é isso que separa uma automação frágil de uma infraestrutura mais confiável.

Principais padrões de nomenclatura

A padronização não se resume apenas a definir o que nomear, mas também o formato a ser usado. Existem quatro estilos de nomenclatura clássicos e amplamente aceitos no universo da Tecnologia da Informação. Saber quando aplicar cada um deles é crucial para a legibilidade do código e a interoperabilidade da arquitetura:

Camel case (camelCase)

Este formato utiliza a primeira palavra em minúsculo e cada palavra subsequente começando com uma letra maiúscula. É ideal para manter nomes compactos e legíveis.

Onde é comum: Variáveis, parâmetros de função e propriedades em linguagens como JavaScript, TypeScript, Go, e também em serialização de dados (ex: JSON).

Por que usar: É o padrão de facto para variáveis em muitas linguagens front-end e back-end, promovendo clareza no contexto de código.

Exemplos: instanceType, userName, maxRetries.

Snake case (snake_case)

Neste estilo, todas as palavras são escritas em minúsculo e separadas por underscores (_).

Onde é comum: Linguagens como Python e Ruby, variáveis de ambiente, estruturas de automação como Terraform e Ansible, e arquivos de configuração (ex: YAML).

Por que usar: É um padrão altamente legível para nomes longos e é historicamente preferido em sistemas Unix-like, além de ser excelente para scripts de shell e automação.

Exemplos: instance_type, user_name, max_retries.

Pascal case (PascalCase)

Semelhante ao Camel Case, porém, todas as palavras — incluindo a primeira — iniciam com letra maiúscula.

Onde é comum: Nomes de Classes, Tipos e Módulos em linguagens orientadas a objetos, como C#, Java e até mesmo classes em Python.

Por que usar: Permite que desenvolvedores distingam rapidamente tipos definidos (classes) de instâncias (variáveis), o que é fundamental para a arquitetura de software.

Exemplos: InstanceType, UserName, MaxRetries.

Kebab case (kebab-case)

O formato Kebab Case utiliza palavras em minúsculo separadas por hifens (-).

Onde é comum: Nomes de Arquivos, Diretórios, recursos web (como URLs), nomes de plugins e em identificadores dentro de Kubernetes (como labels).

Por que usar: É o padrão mais limpo e amigável para contextos de configuração (ex: YAML e JSON), além de ser facilmente interpretado por navegadores e sistemas de arquivos.

Exemplos: instance-type, user-name, max-retries.

O Padrão de variáveis em ferramentas de IaC/DevOps

Terraform

O Terraform adota o padrão snake_case para variáveis e recursos.

variable "instance_type" { 
	description = "Tipo da instância EC2" 
	type = string 
	default = "t3.medium" 
} 
resource "aws_instance" "web_server" { 
	ami = "ami-123456" 
	instance_type = var.instance_type 
}

Ansible

O Ansible também segue o snake_case. Isso vale para variáveis, playbooks e roles.

vars:
  app_port: 8080
  db_host: "database.internal"
  max_connections: 100

Kubernetes

No Kubernetes, os nomes seguem o padrão kebab-case para objetos e snake_case ou camelCase para chaves internas de configuração (dependendo do contexto). Não se pode falar mal do K8s por que ele é o queridinho do universo, masssss poderia ter um padrão só, né chefe? Sim, mas tem uma explicação ;).

• No formato kebab-case

apiVersion: v1 
kind: Service 
metadata: 
	name: web-service 
spec: 
	selector: 
		app: web-server 
	ports: 
		- port: 80 
		  targetPort: 8080

• No formato camel e snake

data: 
	max_retries: "5" 
	logLevel: "info"

CURIOSIDADE - Você já se perguntou por que o Kubernetes utiliza o formato kebab-case (nomes com hifens, como my-service-api) para serviços, deployments e outros objetos? A razão é simples: dentro do Kubernetes existe um DNS interno. Quando os objetos são criados, eles automaticamente geram registros de DNS para permitir a comunicação entre os componentes do cluster. O formato kebab-case é o mais compatível com as regras de nomes de domínio, garantindo que esses registros sejam válidos e resolvidos corretamente.

Conclusão

No contexto de Infraestrutura como Código (IaC), onde a infraestrutura é tratada como software, padronizar e seguir convenções de nomenclatura vai muito além de estética é um imperativo de engenharia que se traduz diretamente em eficiência e ganhos de negócio.

Ao adotar e aplicar de forma consistente um padrão de nomes dependendo da ferramenta sua equipe começa a perceber resultados imediatos nos seguintes itens:

• Desenvolvimento mais rápido, com um código previsível e intuitivo, ninguém perde tempo “decifrando” scripts antigos. O foco volta a ser o que realmente importa: novas features e inovação.

• Menos erros e mais confiabilidade, a consistência reduz falhas de referência em variáveis e recursos, garantindo idempotência, estabilidade e deploys mais seguros.

• Onboarding acelerado, novos engenheiros entendem rapidamente o padrão e conseguem contribuir desde cedo. A colaboração flui porque todos falam a mesma “língua técnica”.

• Código mais limpo e sustentável, um código IaC padronizado é mais fácil de manter e evoluir. Isso reduz dívida técnica e permite que a infraestrutura escale com previsibilidade e segurança.

No fim das contas, o veredito é simples: ter disciplina na nomenclatura é um dos investimentos de menor custo e maior retorno em um pipeline de DevOps. É a base de qualquer projeto de IaC que busca escala, consistência e excelência operacional.

Abraços!

Vida longa e próspera a todos!!

Referências

• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• Terraform Language - Variables
• Ansible Documentation - Variables
• Kubernetes Documentation - Environment Variables
• GitLab CI/CD - Predefined variables reference
• Azure Pipelines - Define variables

Entre em contato: