Código limpo em Swift: como escrever para que seus colegas não te amaldiçoem

Como escrever código limpo em Swift: guia para quem respeita a si mesmo e aos colegas

Todo desenvolvedor já abriu pelo menos uma vez um projeto escrito há seis meses e não conseguiu entender o que estava acontecendo. Ou recebeu um comentário na revisão de código: "Isso poderia ter sido escrito de forma mais simples". Familiar? Se sim, este artigo é para você.

Código limpo em Swift não é apenas um capricho de perfeccionista. É uma ferramenta que economiza horas de depuração e nervos. Quando você escreve com cuidado, não só acelera seu trabalho, mas também torna o projeto transparente para a equipe. Vamos analisar como transformar seu código Swift em uma obra de arte.

Regra nº1: Nomenclatura é a chave de tudo

O pecado mais comum é nomear uma variável como x ou temp. Depois vem outro desenvolvedor e se pergunta: "O que é x? Coordenada? Quantidade?"

Em Swift, é comum dar nomes que são lidos como frases. Isso não é apenas bonito – ajuda a entender imediatamente o que o código faz.

// Ruim\nlet a = 5.0\nvar b = "João"\n\n// Bom\nlet discountRate = 5.0\nvar userName = "João"

Para funções e métodos, vale a mesma regra. O nome deve responder à pergunta "O que este método faz?". Use verbos no imperativo:

// Ruim\nfunc data() -> [String] { ... }\n\n// Bom\nfunc fetchUsers() -> [String] { ... }

E se a função retornar um valor booleano, comece o nome com is, has ou contains:

func isUserLoggedIn() -> Bool\nfunc hasValidEmail() -> Bool

Regra nº2: Opcionais não são inimigos, mas ferramentas

Muitos iniciantes têm medo de opcionais e tentam se livrar deles a qualquer custo. Eles escrevem if let em todo lugar ou, pior ainda, fazem force unwrap. Mas código limpo em Swift é código que trabalha com nil de forma segura.

Lembre-se: ! é um grito de socorro. Use-o apenas se tiver absoluta certeza de que o valor não é nil (por exemplo, ao trabalhar com IBOutlet).

// Código perigoso\nlet name = optionalName!\n\n// Versão segura\nguard let name = optionalName else {\n    return\n}\nprint(name)

E para encadeamentos de opcionais, use ? e nil-coalescing:

let userCity = user?.address?.city ?? "Desconhecido"

Este código não quebrará, mesmo que user ou address sejam nil. E é lido como uma frase normal: "Cidade do usuário ou 'Desconhecido'".

Regra nº3: Structs em vez de classes (quando possível)

Em Swift existem tanto classes quanto structs. Mas muitos, por hábito, usam classes em todo lugar. E é um erro. Structs são value types e são mais seguras em código multithread. Além disso, são copiadas, não referenciadas, o que reduz o risco de efeitos colaterais.

Use struct quando:

\n
• Precisar armazenar dados sem lógica complexa
\n
• Não houver necessidade de herança
\n
• O objeto não precisar ser mutável após a criação
\n

// Melhor usar struct\nstruct User {\n    let id: Int\n    var name: String\n}\n\n// Classe – apenas se precisar de herança ou reference semantics\nclass ViewController: UIViewController { ... }

A propósito, a Apple recomenda usar structs para modelos de dados. Este é um dos principais princípios do código limpo em Swift.

Regra nº4: Protocolos são seus melhores amigos

Protocolos em Swift não são apenas interfaces. São uma forma de tornar o código flexível e testável. Em vez de se prender a uma classe específica, trabalhe através de um protocolo.

protocol NetworkServiceProtocol {\n    func fetchData(completion: @escaping (Result<Data, Error>) -> Void)\n}\n\nclass APIService: NetworkServiceProtocol { ... }\nclass MockService: NetworkServiceProtocol { ... }

Agora você pode facilmente substituir o serviço real por um mock para testes. E não precisa alterar o código em outro