Autor: Artur Baccarin

As funções init são funções especiais que são executadas antes de qualquer função no código.

Elas são a terceira etapa na ordem de inicialização de um programa em Go, sendo:

1. Os pacotes importados são inicializados;
2. As variáveis e constantes globais do pacote são inicializadas;
3. As funções init são executadas.

Seu uso mais comum é preparar o estado do programa antes da execução principal na main, como por exemplo: verificar se variáveis de configuração estão corretamente definidas, checar a existência de arquivos necessários ou até mesmo criar recursos ausentes.

É possível declarar várias funções init em um mesmo pacote e em pacotes diferentes, desde que todas utilizem exatamente o nome init.

Quando isso ocorre, a ordem de execução delas é a seguinte dependendo do caso:

Em pacotes com dependência entre si

Se o pacote A depende do pacote B, a função init do pacote B será executada antes da função init do pacote A.

O Go garante que todos os pacotes importados sejam completamente inicializados antes que o pacote atual comece sua própria inicialização.

Essa dependência entre pacotes também pode ser forçada usando o identificador em branco, ou blank identifier (_), como no exemplo abaixo que o pacote foo será importado e inicializado, mesmo que não seja utilizado diretamente.

Múltiplas funções init no mesmo arquivo

Quando existem várias funções init no mesmo arquivo, elas são executadas na ordem em que aparecem no código.

Múltiplas funções init em arquivos diferentes do mesmo pacote

Nesse caso, a execução segue a ordem alfabética dos arquivos. Por exemplo, se um pacote contém dois arquivos, a.go e b.go e ambos possuem funções init, a função em a.go será executada antes da função em b.go.

No entanto, não devemos depender da ordem de execução das funções init dentro de um mesmo pacote. Isso pode ser arriscado, pois renomeações de arquivos podem alterar a ordem da execução, impactando o comportamento do programa.

Apesar de úteis, as funções init possuem algumas desvantagens e pontos de atenção que devem ser levados em conta na hora de escolher usá-las ou não:

1. Elas podem dificultar o controle e tratamento de erros, pois já que não retornam nenhum valor, nem de erro, uma das únicas formas de tratar problemas em sua execução é via panic, que causa a interrupção da aplicação.
2. Podem complicar a implementação de testes, por exemplo, se uma dependência externa for configurada dentro de init, ela será executada mesmo que não seja necessária para o escopo dos testes unitários. Além de serem executadas antes dos casos de teste, o que pode gerar efeitos colaterais inesperados.
3. A alteração do valor de variáveis globais dentro da função init pode ser uma má prática em alguns contextos:
   • Dificulta testes: como o estado global já foi definido automaticamente pela init, é difícil simular diferentes cenários ou redefinir esse estado nos testes.
   • Aumenta o acoplamento: outras partes do código passam a depender implicitamente do valor dessas variáveis globais, tornando o sistema menos modular.
   • Reduz previsibilidade: como a inicialização acontece automaticamente e sem controle do desenvolvedor, fica mais difícil entender ou modificar o fluxo de execução do programa.
   • Afeta reutilização: bibliotecas que dependem de init com variáveis globais são menos reutilizáveis, pois forçam comportamentos no momento da importação.
     

Em resumo, as funções init são úteis para configurações iniciais, mas seu uso deve ser criterioso, pois podem dificultar testes, tratamento de erros e tornar o código menos previsível.

Referência: HARSANYI, Teiva. 100 Go mistakes and how to avoid them. Shelter Island: Manning, 2022.

Um modelo mental, no contexto de software, é a representação interna que um desenvolvedor constrói para compreender como um sistema ou trecho de código funciona. Ele não é visível, mas sim uma estrutura de raciocínio que permite prever o comportamento do sistema com base no conhecimento adquirido até aquele momento.

Durante a leitura ou escrita de código, o desenvolvedor precisa manter esse modelo atualizado para entender, por exemplo, quais funções interagem entre si, como os dados fluem e quais efeitos colaterais podem ocorrer.

Códigos com boa legibilidade exigem menos esforço cognitivo para manter esses modelos mentais coerentes e atualizados.

Um dos fatores que contribuem para uma boa legibilidade é o alinhamento do código.

Na Golang UK Conference de 2016, Mat Ryer apresentou o conceito de line of sight in code (“linha de visão no código”, em tradução literal). Ele define linha de visão como “uma linha reta ao longo da qual um observador tem visão desobstruída”.

Aplicado ao código, isso significa que uma boa linha de visão não altera o comportamento da função, mas torna mais fácil para outras pessoas entenderem o que está acontecendo.

A ideia é que o leitor consiga acompanhar o fluxo principal de execução olhando para uma única coluna, sem precisar pular entre blocos, interpretar condições ou navegar por estruturas aninhadas.

Uma boa prática é alinhar o caminho feliz da função à esquerda do código. Isso facilita a visualização imediata do fluxo esperado.

O caminho feliz é o fluxo principal de execução de uma função ou sistema, em que tudo ocorre como esperado sem erros, exceções ou desvios.

Na imagem a seguir é possível visualizar um exemplo de caminho feliz:

De modo geral, quanto mais níveis de aninhamento uma função possui, mais difícil ela se torna de ler e entender, além de ocultar o caminho feliz, como podemos ver na imagem abaixo:

Mat Ryer em seu artigo Code: Align the happy path to the left edge apresenta mais dicas para uma boa linha de visão, sendo elas:

Retorne o mais cedo possível de uma função. Essa prática melhora a legibilidade porque reduz o aninhamento e mantém o caminho feliz limpo e direto.

Evite usar else para retornar valores, especialmente quando o if já retorna algo. Em vez disso, inverta a condição if (flip the if) e retorne mais cedo, deixando o fluxo principal fora do else.

Coloque o retorno do caminho feliz (o sucesso) como a última linha da função. Isso ajuda a deixar o fluxo principal claro e previsível. Quem lê sabe que, se nada der errado, o sucesso acontece no final.

Separe partes da lógica em funções auxiliares para que as funções principais fiquem curtas, claras e fáceis de entender. Funções muito longas e cheias de detalhes dificultam a leitura e a manutenção.

Se você tem blocos de código muito grandes e indentados (por exemplo, dentro de um if, for ou switch), considere extrair esse bloco para uma nova função. Isso ajuda a manter a função principal mais plana, legível e fácil de seguir, evitando profundidade excessiva e “efeito escada” no código.

Em resumo, cuidar da legibilidade do código é essencial para manter modelos mentais claros. Práticas como alinhar o caminho feliz, evitar aninhamentos profundos e extrair funções tornam o código mais fácil de entender, manter e evoluir.

Referências:

HARSANYI, Teiva. 100 Go mistakes and how to avoid them. Shelter Island: Manning, 2022.

RYER, Mat. Code: Align the happy path to the left edge. 2016. Disponível em: https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88. Acesso em: 05 jul. 2025.

Escopo de variável é o espaço do código onde uma variável pode ser utilizada.

No Go, variáveis declaradas no nível de pacote podem ser usadas dentro de funções do mesmo pacote. Variáveis declaradas dentro de uma função podem ser usadas dentro de blocos de decisão (if) e de repetição (for).

Porém, uma variável de um escopo mais externo (como o nível de pacote ou função) pode ser redeclarada em escopos internos, causando o sombreamento de variável. Isso pode gerar confusão e bugs.

No exemplo abaixo, a variável debugMode é redeclarada dentro da função com o operador de declaração curto (:=), criando uma nova variável local e não alterando a variável do pacote como esperado:

Outro caso é quando usamos o operador de declaração curto (:=) dentro de um bloco if com múltiplos retornos de uma função. No exemplo abaixo, a variável foo é redeclarada dentro do if, sombreando a variável do nível da função e deixando a variável original inalterada:

Para evitar esse problema, a variável de erro deve ser declarada antes do retorno da função e o operador de atribuição simples (=) deve ser utilizado para modificar a variável existente, assim:

Em resumo, o sombreamento acontece quando uma variável é redeclarada em um escopo mais interno, escondendo a original. Para evitar erros, use o operador de atribuição (=) para atribuir valores a variáveis já declaradas e evite redeclarar variáveis com o mesmo nome em escopos próximos.