Code Review em Swift: 10 coisas que verifico em primeiro lugar

Por que Code Review em Swift não é sobre picuinhas

Imagine a situação: você abre um pull request de um colega, vê 500 linhas de código Swift e percebe que em 20 minutos começa a daily. Familiar? Code review (ou revisão de código) não é uma competição de "quem encontra mais erros de digitação". É sua chance de prevenir bugs em produção, melhorar a arquitetura e transmitir conhecimento para a equipe.

Neste artigo, reuni uma checklist de code review para Swift que eu mesmo uso. Sem enrolação — apenas verificações específicas, exemplos de código e explicações do porquê isso é importante. Mesmo que você programe em Python, mas esteja explorando o mundo do desenvolvimento iOS, o material será útil.

1. Segurança de memória e tipos opcionais

O Swift se orgulha de sua segurança de memória, mas isso não significa que você pode relaxar. O problema mais comum é o force unwrapping. Cada ponto de exclamação é uma potencial falha.

O que verificar:

\n
• Force unwrap (!) — só é aceitável em testes ou quando você tem 100% de certeza do valor. Em código de produção, é uma bandeira vermelha.
\n
• IUO (Implicitly Unwrapped Optionals) — use-os apenas para IBOutlet ou propriedades que são inicializadas após init, mas antes do primeiro uso.
\n
• Retain cycles — verifique closures quanto à presença de [weak self] ou [unowned self].
\n

// Ruim: force unwrap sem verificação\nlet url = URL(string: "https://pythonlib.ru")! // Falha se a string for inválida\n\n// Bom: guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n    print("URL inválida")\n    return\n}\n\n// Verificação de retain cycle em closure\nclass NetworkManager {\n    var completionHandler: (() -> Void)?\n    \n    func fetchData() {\n        completionHandler = { [weak self] in\n            guard let self = self else { return }\n            self.updateUI() // self agora é uma referência fraca\n        }\n    }\n    \n    func updateUI() { /* ... */ }\n}\n

Dica para code review: se você vir !, pergunte "por que não usar guard ou if let aqui?". Isso evitará muitas falhas.

2. Tratamento de erros: não engula exceções

O Swift oferece um mecanismo poderoso com do-catch, mas os desenvolvedores frequentemente o ignoram. Um antipadrão típico é try! ou um catch vazio.

O que verificar:

\n
• try! — quase sempre é prejudicial. Só use se estiver escrevendo um teste.
\n
• catch {} vazio — você está apenas perdendo informações sobre o erro. No mínimo, registre-o.
\n
• Propagação de erros para cima (throws) — a função deve tratar o erro ou propagá-lo explicitamente.
\n

// Ruim: engolindo o erro\ndo {\n    let data = try fetchData()\n} catch {\n    // Não fazemos nada — o erro foi perdido\n}\n\n// Bom: registramos e mostramos ao usuário\ndo {\n    let data = try fetchData()\n    updateUI(with: data)\n} catch let error as NetworkError {\n    showAlert(message: error.localizedDescription)\n} catch {\n    print("Erro desconhecido: \\(error.localizedDescription)")\n    showGenericError()\n}\n

No code review para Swift, sempre verifique se o Error não está sendo simplesmente ignorado. O usuário precisa entender o que deu errado.

3. Arquitetura: MVC, MVVM ou VIPER?

Não importa qual padrão você escolheu — o importante é que o código siga esse padrão. No code review, você percebe se o ViewController se transformou em um "God Object" (uma classe que faz tudo).

O que verificar:

\n
• Tamanho do arquivo — se um único arquivo tem mais de 300-400 linhas, é um motivo para pensar em dividi-lo.
\n
• Responsabilidade das classes — o ViewController não deve fazer requisições de rede ou analisar JSON. Para isso, existem serviços e gerenciadores.
\n
• \n