Equipe Swift sem caos: code style e convenções que salvarão seu projeto

Como não se afogar no código alheio: introdução ao code style Swift

Imagine: você abre um pull request de um colega e lá — let userName convive com let UserName, as indentações variam de 2 a 8 espaços, e as chaves estão ora na mesma linha, ora na linha seguinte. Familiar? Se sua equipe escreve em Swift, mais cedo ou mais tarde você enfrentará o caos. Ou já enfrentou.

Trabalhar em equipe não é sobre "como é conveniente para mim", mas sobre "como é compreensível para todos". Code style e convenções para Swift não são burocracia, são uma tábua de salvação. Eles economizam horas em code review, reduzem a quantidade de bugs e tornam o código legível mesmo depois de seis meses. Neste artigo, contarei quais regras realmente funcionam, mostrarei exemplos em Swift e darei um checklist para implementação na sua equipe. Vamos lá!

Por que sem code style Swift se transforma em um inferno

Swift é uma linguagem jovem, mas rigorosa. Ela mesma incentiva a organização: optionals, generics, protocols. Mas sem acordos internos na equipe, nem mesmo a sintaxe ideal salva. Aqui estão três razões pelas quais Swift code style é necessário em todo projeto:

\n
• Velocidade de onboarding. Um novo desenvolvedor passa dias estudando não a lógica, mas "onde está o quê".
\n
• Code review. Em vez de discutir arquitetura, vocês discutem espaços. Dor familiar?
\n
• Dívida técnica. Estilos diferentes — lógicas diferentes. Um dia isso vai explodir em produção.
\n

A boa notícia: as convenções Swift já foram criadas. Só falta combinar e automatizar.

Nomenclatura: Swift Naming Convention

Swift é uma linguagem com uma filosofia clara: "clareza é mais importante que brevidade". Isso significa que getUserData() é ruim, e fetchUserProfile() é bom. Vamos analisar as regras principais da Swift naming convention.

Variáveis e constantes

Use camelCase com letra minúscula. Nomeie as entidades de forma que fique claro sem comentário:

// Ruim\nlet n = "Alice"\nlet u = 25\n\n// Bom\nlet userName = "Alice"\nlet userAge = 25\n\n// Ótimo (com tipo)\nlet isActiveUser: Bool = true\n

Para variáveis booleanas, adicione prefixos is, has, should — isso é best practice Swift.

Funções e métodos

Funções devem ser lidas como uma frase. Verbo + substantivo é a regra de ouro:

// Ruim\nfunc change() { }\nfunc processData() { }\n\n// Bom\nfunc updateUserProfile() { }\nfunc validateEmailAddress() { }\n\n// Com parâmetros — ainda mais legível\nfunc configureButton(withTitle title: String, color: UIColor) { }\n

Observe: o primeiro parâmetro geralmente é omitido na chamada, mas para legibilidade é melhor indicá-lo explicitamente. Isso faz parte do Swift code style guide da Apple.

Tipos e protocolos

Classes, structs, enum — PascalCase. Protocolos também, mas tente torná-los nomes de adjetivos:

class UserManager { }\nstruct UserProfile { }\nenum NetworkError { }\n\nprotocol Configurable { }\nprotocol DataPersistable { }\n

Formatação: respire uniformemente

Tema de discussões acaloradas — indentação, chaves, espaços. Vamos esclarecer de uma vez. Para Swift code style, recomendo seguir o padrão do SwiftLint (falaremos dele depois).

Chaves

A Apple recomenda colocar a chave de abertura na mesma linha (estilo K&R). A chave de fechamento, na linha seguinte:

// Correto\nif isLoggedIn {\n    showDashboard()\n} else {\n    showLoginScreen()\n}\n\n// Incorreto\nif isLoggedIn\n{\n    showDashboard()\n}\n

Exceção — closures. Lá as chaves podem estar na mesma linha, se o código for curto:

let sortedUsers = users.sorted { $0.age < $1.age }\n