Logo 61e73bc61c0e1780102320e879dc3cac0e29303ea8894dd8f10c942f3ba8120f

otters.io

An adorable little blog

Writing Swifter Swift

Tuesday — April 26th, 2016

Swift bird

What does good Swift look like? This question lingers with those well-versed in Apple’s development platforms as well as newcomers. Does it look like good Objective-C? No, Swift isn’t Objective-C; So it has to be different right?

Luckily, Apple has laid out a very pleasant set of API design guidelines that give an idea of what the Swift of today and tomorrow should look like. You can (and should) give them a read through at least once, but here's a quick take away for the lazy:

Clarity, Clarity, Clarity

Clarity is more important than brevity and redundancy is not clarity. Succinct code is nice where it comes up naturally but you shouldn’t work to shoehorn code into a character limit. Avoid abbreviations that haven’t been made by a large and boring committee. URL is fine, IDKMyBFFJill probably isn’t.

You should be clear about the context and side effects of your methods. myToDoList.remove(x) is unclear because a list can have something removed by index or by value. A better option would be  myToDoList.remove(at: x) and myToDoList.remove(member: x). Whereas mySet.remove(x) is completely acceptable because a set should not be ordinal and saying mySet.removeElement(x) is redundant.

Following the need to make your functions clear, if a function is mutating it should be obvious from the name. A good example is myToDoList.sort() and myTodoList.sorted(). In this case, sort() would mutate myTodoList and sorted() would return a sorted copy of it.

You should write a documentation comment. It’s boring, it’s tedious, and it’s really handy for everyone who isn’t you right now. Even if you’re the only one working on this code, future you will read it as a different person and be grateful for your sacrifice. Feel free to use Markdown.

Another swift bird

Finally, embrace precedent. Precedent should be clear for those who’ve seen it and easy to google for those who haven’t. Don’t write code that is easier to read for people new to programming than it is for people who are new to Swift. If there is no Swift-specific precedent, follow the existing Objective-C precedent. If there is no Objective-C precedent, look for a C precedent.