Airside MobileSenior iOS developer2019 – 2020
A Swift style guide nobody had to be talked into.
Our iOS developers worked on different products, and each product’s Swift looked a little different. I asked everyone for the Swift style guides they actually liked, and we built ours out of the overlap. The only arguments left were the contradictions, and those had a tie-breaker. Then iOS developers on every product started using it.
Problem
Reviews argued about formatting instead of logic. Swift that moved between products looked foreign on arrival.
My part
Ran the process and wrote the guide.
Hard call
Only argue about contradictions. Overlap: adopted. Unique to one guide: adopted. Contradiction: whichever is easier to read, and if both are, whichever is less code.
Result
One Swift style guide. iOS developers across products started using it on their own. No big fight, because almost nothing in it was new to anyone.
Start from what people already like
Instead of writing a guide and defending it, I asked every iOS developer for the Swift style guides they already followed or admired. That made the input everyone’s, not mine.
Merge by rule, not by taste
Where guides agreed, we adopted the rule as written. Where a rule appeared in only one guide and nobody objected, we adopted it too. That covered most of the document before anyone had to argue.
The tie-breaker
Contradictions got one question: which is easier to read? If both were, which is less code? It’s a rule people can apply without me in the room, which is why it held.
Adoption
Nobody mandated it. iOS developers working on different products started using it, one by one, because it already looked like the code they liked. Other engineers’ Swift got more consistent because of a process I ran, not a rule I handed down.