Constantes e iota: valores que o compilador garante que nunca mudam

O formato do problema é uma tabela: para cada valor de entrada conhecido, uma saída fixa; para todo o resto, um valor padrão. A implementação mais direta espelha a tabela — uma comparação por nível, cada uma com return direto, e o caso desconhecido como última linha:

func LevelName(level int) string {
	if level == LevelDebug {
		return "DEBUG"
	}
	if level == LevelInfo {
		return "INFO"
	}
	if level == LevelWarning {
		return "WARNING"
	}
	if level == LevelError {
		return "ERROR"
	}
	return "UNKNOWN"
}

Custo O(1) — quatro comparações no pior caso. O return "UNKNOWN" final não precisa de else: se a execução chegou ali, nenhum nível bateu. Note também o que a função devolve para entrada inválida: um valor definido pelo contrato, não um panic nem uma string vazia — quem chama consegue tratar o caso sem surpresa. (Na aula 8 você reescreve exatamente esta função com switch, a ferramenta desenhada para este formato; a versão com ifs é a base honesta para comparar.)

A alternativa que passa nos testes hoje e falha no futuro: if level == 0 { return "DEBUG" }. Os números estão certos — até alguém inserir LevelTrace no topo do bloco const, o que desloca todos os iota uma posição. E esse tipo de inserção acontece: níveis de log, status de pedido e categorias de produto são listas vivas, que crescem conforme o sistema cresce. O autor da mudança vai olhar o bloco de constantes, ver que tudo continua compilando e seguir em frente — ele não tem como saber que, em outro arquivo, alguém comparou com o número cru em vez do nome. As comparações por nome continuam corretas automaticamente após essa mudança; as por número passam a mentir, e o pior tipo de mentira: sem erro de compilação, só logs classificados errado em produção. A constante nomeada não é decoração — é o único vínculo que sobrevive à evolução do código. Esse é, aliás, o argumento completo contra números mágicos: o literal 2 espalhado pelo código não tem como ser atualizado com segurança, porque nem todo 2 é LevelWarning.

O enunciado “a maior unidade que couber” já dita a estrutura: as comparações precisam começar pela maior unidade, porque é ela que tem prioridade quando mais de uma serve. Da maior para a menor:

func HumanBytes(bytes int) string {
	if bytes >= GB {
		return fmt.Sprintf("%d GB", bytes/GB)
	}
	if bytes >= MB {
		return fmt.Sprintf("%d MB", bytes/MB)
	}
	if bytes >= KB {
		return fmt.Sprintf("%d KB", bytes/KB)
	}
	return fmt.Sprintf("%d B", bytes)
}

A ordem decrescente é o algoritmo: “a maior unidade que couber” significa que GB tem prioridade sobre MB, que tem prioridade sobre KB. Cada return corta a execução, então quem passa do primeiro if já se sabe menor que 1 GB, e assim por diante — as condições seguintes não precisam reafirmar esse limite superior, porque a estrutura já o garante. A divisão inteira da aula 3 faz o arredondamento para baixo de graça: 2047/1024 é 1, sem nenhuma chamada de arredondamento explícita. Custo O(1).

A armadilha é inverter a ordem: testar bytes >= KB primeiro captura todo valor acima de 1024 — incluindo os 5242880 bytes do caso 4, que sairiam como "5120 KB" em vez de "5 MB". A condição não está errada; está na posição errada, e é por isso que esse bug engana: cada if isolado é verdadeiro quando dispara, então nenhuma leitura linha a linha encontra o defeito — só a leitura da estrutura como um todo, perguntando qual condição captura o quê antes de quem. Em cadeias de faixas, a regra geral é testar da condição mais restritiva para a mais ampla. E repare no papel das constantes: bytes >= 1073741824 seria ilegível e conferível só com calculadora; bytes >= GB é autoexplicativo e gerado pelo compilador a partir do 1 << (10 * iota) — impossível digitar errado.

A função tem quatro respostas possíveis, mas só três decisões reais: a entrada é válida? É um dos dois dias especiais? Tudo o mais é dia útil. A implementação espelha essa análise — valide primeiro, trate os especiais, deixe o comum para o fim:

func ShippingDays(day int) int {
	if day < Sunday || day > Saturday {
		return -1
	}
	if day == Saturday {
		return 2
	}
	if day == Sunday {
		return 1
	}
	return 0
}

A estrutura em retornos antecipados — inválido, especial, especial, comum — é a mesma do exercício 2 da aula 2, e vai ser o esqueleto da maior parte das suas funções Go: cada if elimina uma categoria, e a última linha atende quem sobrou (segunda a sexta), sem precisar reenumerá-los. Validar a entrada antes de qualquer outra decisão não é só organização: garante que as comparações seguintes trabalham sobre um valor que já provou estar no domínio, então nenhuma delas precisa se defender de novo. Os limites do intervalo usam Sunday e Saturday pelos nomes, pela mesma razão do exercício 1 — se a semana um dia mudar de numeração, a validação acompanha sem edição. Custo O(1).

Agora, o detalhe de design que o caso 5 cobra: a enumeração começa em 1 de propósito. Pense no caminho completo do bug evitado: um struct de pedido é criado em outra parte do sistema, alguém esquece de preencher o campo do dia, e o campo — como toda variável de Go — nasce com o zero value. Se Sunday fosse 0 — como sairia de um iota puro —, esse pedido esquecido seria silenciosamente um pedido de domingo, e a função responderia 1 com toda a confiança de quem recebeu um dado válido; nenhum teste de tipo, nenhum compilador e nenhum log apontaria o problema. Com a enumeração começando em 1, o zero value cai na faixa inválida e a função responde -1 — o esquecimento vira sinal detectável em vez de bug silencioso. Guarde esse truque: ao desenhar enumerações com iota, reserve o zero para “não definido” sempre que o zero value puder chegar à sua função por omissão. A armadilha correspondente é começar em iota puro por inércia e nunca perceber que o estado “vazio” coincide com o primeiro estado válido.