Apple is Wrong! (In this small way)

How should you section off your delegate (and datasource) methods? I have seen (so far) two ways that Apple does so in their templates:

  1. ‘Brief’ Format:

// MARK: - Table View

2. ‘SeparateComponentsWith ” ” ‘ Format:

// MARK: - Table view data source

What this misses:

  • Firstly, the idea of having a plain-English pragma mark does not make sense – we should not be reading the pragma marks — not when there is an immediately recognizable heiroglyph such as UISomeAPIiKnowBySight.
  • Secondly, this version…

// MARK: - UITableViewDataSource

…can be ⌘-clicked to take you to the docs and/or implementation of the API in question, which makes so much sense – put the instructions next to the tools in case they are needed.

So I change all boilerplate templates to conform their respective APIs. While those two reasons are not earth-shattering, they are compelling enough that I will not forget (or rather, can ‘re-derive’) which convention I adhere to, consistently. Consistency in coding is a very powerful contributor to readability, so sign me up.

So, who is going to let Apple know that they got this one wrong?

 

Book Review: The Swift Developer’s Cookbook, by Erica Sadun

240 pages, Addison-Wesley Professional, 1st ed (19 Dec 2015)

tl;dr

In sum, if you are a moderately experienced in Objective-C, this petite volume covers basically the same ground as Apple’s Swift Programming Language, but written in a problem-solution style, with the added value of her non-Apple perspective — oh, and did I mention that she does this all in 1/3 of the space (~200 pages to SPL’s 600+). The title “Swift for the Really Impatient” is apparently already taken, but would fit this book quite well. Highly recommended, if you’re her target audience.

—-

Are you an Objective-C developer looking for an advanced primer to dive into Swift? Then look no further. Erica Saudi’s slim volume is densely packed with well-written code that tersely explains (a) how to do Objective-C tasks in Swift syntax, and (b) how to avoid that road, and take advantage of Swift to accomplish those tasks Swift-ly.

Those who have read her other books, such as iOS Autolayout Demystified, or follow her blog, know you are in good hands with a professional who has a deep and intimate knowledge of the inner workings of the Cocoa APIs, and like a good tour guide, can point out common hazards to avoid as she takes you on the safe path. Moreover, she provides ‘historical’ context about what came before. And throughout are little gems of humor.[1]

This book is not for everyone, but it may very well be for you. It is certainly not for fresh beginners, and it is not for someone looking to learn iOS programming or APIs. Myself, I have been programming in Objective-C for about a year now, and just completed my first Swift project when I got my hands on the book, which I saw as a time-saving alternative to scouring the tech-blogosphere and weeding out the Swift 1.x stuff from the Swift 2.x. Rather than read it cover to cover, I read the chapter I needed to bone up on, or searched the index — and in this regard, it works quite well, as a ‘cookbook’ should (though it is not really a cookbook, as I’ve seen the term used, such as in “The iOS Developer’s Cookbook” by the same author — the code provided are mostly of snippet-length).

In sum, if you are a moderately experienced in Objective-C, this petite volume covers basically the same ground as Apple’s Swift Programming Language, but written in a problem-solution style, with the added value of her non-Apple perspective — oh, and did I mention that she does this all in 1/3 of the space (~200 pages to SPL’s 600+). The title “Swift for the Really Impatient” is apparently already taken, but would fit this book quite well. Highly recommended, if you’re her target audience.

Note that this cookbook is focused on Swift, not Cocoa, as in the iOS Developer’s Cookbook by the same publisher. Double-check the table of contents to make sure it covers the topics you require.

[1] My favorite:
“Uppercase function names are immediately distinguishable from methods but are currently out of fashion. This practice was quite common up to and including name-spacing, when it suddenly went extinct. It’s like a million capitalized voices cried out and were suddenly silenced.”
(p.68 / Kindle Locations 2086-2088).

Full Disclosure: I purchased a dead tree copy of the book for my own edification. Subsequently, I was offered a free copy in exchange for an honest review, which got me the electronic version. So, to be honest, I have issues with all programming e-books and how they fail to display code in a helpful manner (read: syntax highlighting!). Dead trees win in that regard, which boggles the mind. But I love having the e-book for searching. I would buy far more books like these if there was an e/tree bundle that was *less* than, say, the price of two full copies!