One of the things Objective-C developers love to hate about the language is the fucking block syntax (disclaimer: I used this website to write the block syntax in some examples!). I certainly understand the sentiment: they are very clumsy to write and get right the first time. If you use Xcode, however, there are some strategies and helpful autocompletion flows that will make your life easier without having to fire up a new browser window.
I never write a method that contains all the clumsy mechanics of a block directly in a parameter type.
Instead, Xcode provides an autocompletion for the string
typedefBlock; start typing that outside of an
@implementation scope, and you can accept an automatic expansion to the following:
This adheres to DRY principles and makes the code more self-documentingly readable. So many times, I’ve seen method after method clumsily spell out the same block signature for passing networking completion blocks down the call stack with the familiar triad of
NSError, when it should have been wrapped up in a
typedefBlock. Removing the actual signature from 20 places to just one would have avoided many permutations of nullability specifiers, types and parameter names between all the instances of the completion signature. you can change it much easier in the future and even add documentation comments!
OK, we’ve now
typedef‘d all of our block declarations, and now we want to call a method containing a completion block. If you have autocompleted a method call that accepts a block as a parameter, you can tab over to that placeholder and hit Return, expanding the full block syntax needed to satisfy the parameter. This really helps me to write blocks that have return values, because for some reason I can never remember that particular piece of gosh darn block syntax.
Xcode has one other helpful snippet to write Objective-C blocks:
inlineBlock. This helps you to declare a block and store it in a variable in local scope. This makes method calls that accept multiple blocks, like
+[UIView animateWithDuration:animations:completion:], more readable at the call site. I prefer this over chaining multiple blocks directly in the parameter positions, which ends up looking awkward in Objective-C syntax and even worse when you’re reading code or diffs in viewers that wrap text.
In general, I don’t fully care for this approach, as you then have to read code upwards. It also annoyingly makes you repeat the parameter list. Most preferable to me is to still declare the blocks as local variables, but extract all the logic you would have written in the block to a method. This approach makes your code more readable, and your logic more testable and refactorable later.
Writing closures in Swift is much easier for me, but I’d still encourage you to
typealias complicated closure types, and you can always visit fucking swift block syntax, fucking closure syntax and of course gosh darn closure syntax, for those of you who’ve already maxed out your cursing jar allowance for the month performing Swift 3 migrations.