Wednesday, June 8, 2016 [Tweets] [Favorites]

Swift Mistakes

Zev Eisenberg:

Even though I’ve been keeping up with Swift blog posts, my first Swift app was a port of an old and crusty Objective-C code base, and I carried over a lot of old habits. In looking back over it, I found many small- to medium-sized changes that make the code cleaner and more Swifty. Maybe I can help you avoid similar mistakes.

[…]

Sadly, you can’t make protocol conformances private, but otherwise you should be using private extensions wherever you aren’t required to make them public.

[…]

There are certainly cases where direct comparison to nil are appropriate, but Swift’s language features make it pretty rare in my experience.

[…]

Since you can extend any type, it’s convenient to make extension files for your utilities on CGRect, CGPoint, UIInterfaceOrientation, and other types that couldn’t be extended when they were lowly C structs. So don’t litter your main code files with one-off domain-specific utilities on system types. Put them in a separate file and write a couple of unit tests just for that file.

Daniel Jalkut:

At first, I didn’t think too much of this bridging header. Sure, I want to access my Objective C files from Swift. Which ones? Why not all of them?

[…]

My takeaway is to accept that it is fundamentally unsafe to interface with Objective C classes whose headers have not been audited for nullability.

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment