Your friend, the comma operator

C has had a comma operator for decades, the primary use of which is to separate function arguments.

By definition, the value of a comma separated statement is the right hand argument:

int i = j = 3, k = 4, l = 5;

sets i to 5, and is evaluated left to right. However, this is not the usage I have found for it.

Rather, I use it to bind statements that I fear some junior engineer is going to separate in the future – by mistake.

For instance:

[timer invalidate];
 timer = nil;

I could of course do:

    [timer invalidate];
     timer = nil;

but that looks like so much work for such a small thing. So instead, what I do is this:

[timer invalidate], timer = nil;

Its inconceivable that some developer in the future will separate those statements.

Thus, you can use the comma to tightly bind two or more statements together in a way that won’t get broken up by mistake.

Thoughts on formatting blocks

When I first started writing serious Objective-C code in 2005, I had the benefit of a stern taskmaster in Aaron Hillegas of the Big Nerd Ranch, on proper style. He read us a list of standards to follow, such as class methods always appear before instance ones, that all braces for methods and ivar wrappers appear as the first character of a line (well I think that’s what he said). In addition, this is the proper method syntax:

- (NSString *)foo:(SomeClass *)name;

The ‘-‘ or ‘+’ the first character, a space, the type, the name, no spaces between the ‘:’ and the next character, etc as you can see.

With blocks, well, I never saw a style I liked in sample code, and the sample code is all over the place in terms of styles. After a few months I’ve settled down to an uncommon style (which I hope to make less common by publicizing it!):

[dict enumerateKeysAndObjectsUsingBlock:^(NSString *key, NSArray *obj, BOOL *stop))
        ... the code
    } ];

Using this style makes it very easy to spot the blocks in code, and also to visually identify where blocks are when you quickly scan a big file.

To my eye, putting the braces directly under the ‘[‘ makes it look too much like a simple C block unconnected to the line above.

Note that I’ve changed the id key and id obj to specific types. I totally forget where I picked this up – I may in fact have just tried to use it and found it would work. It sure saves me a lot of time in created a second object casted to the id value or using one or more casts within an expression.

When I assign a block variable, it gets a bit more tricky, but this is what I do for multi-line blocks:

dispatch_block_t b = ^{
                          ... code

I’ve really gotten to like this style, now with my strong opinions on C, Objective-C, and blocks styles I’m afraid I’ll never be able to integrate into a coding group that has already written a style guide. YMMV

Best Practices for Xcode Configurations

When you create a project, Xcode gives you Development and Release configurations. The former has DEBUG set to 1 and the optimizer turned off. The latter uses an optimizer setting of -Os (optimize for speed and size together), which is what I always use on submitted apps. Together these are not enough to thoroughly develop and test your app! I just cannot emphasize enough how important it is to add more configurations, and to use them judiciously.

You should add two new configurations, Distribution and ReleaseWithAsserts. The former is used to build the release that gets put into the store (or otherwise distributed to customers), and the latter is the one you will use most during development.

  • Deployment: a Release clone, it adds a define to the Preprocessor Macros DEPLOYMENT, so that code that does say push notifications uses the proper information. It also has NS_BLOCK_ASSERTIONS=1 and NDEBUG, which disable NSAsserts() and asserts() respectively.
  • Release: used for ad hoc or local testing, and it may pull in the development push server or modify some settings necessary for ad hoc testing. As provided by Apple but with the two assertion flags: NS_BLOCK_ASSERTIONS=1 and NDEBUG.
  • ReleaseWithAsserts: a pure Release clone.
  • ReleaseWithAssertsUnitTesting: a  Release clone with a UNIT_TESTING flag.
  • Debug: as provided by Apple.

Screen Shot 2013-04-25 at 12.25.13 PM

The reasoning is as follows. Sprinkle your code with as many asserts()/NSAsserts() as possible, to catch logic and pure coding errors as soon as possible. These will only be compiled into the code for Debug and ReleaseWithAsserts.

So many developers I’ve met use Debug for all development, and only switch to Release when done. This is a huge mistake as the compiled code is hugely different between optimized and raw unoptimized code. Particularly now with ARC, so many retains and releases obviated by ARC stay in the code. Debug compiled code runs slower, uses bloated machine code, and is many ways is quite different from what you will ultimately ship. ARC issues may never appear with Debug, only showing themselves at the last minute when you test with Release. Do yourself a huge favor and only use Debug for its true purpose: working with the debugger tracking down crashes or bugs.

The reason you want Debug for bug resolution is that truely every line of code in your program will match some machine code. With the optimizer, the one to one relationship is lost, and the compiler can reorganize your code and even remove some of it. When you need Debug you need it!

Also, so now that you have the assert flags to differentiate tested or distributed code, you can add other checks and/or logs into the code, by wrapping it with #ifndef NDEBUG (a double negative!).

I also add a line to any code wrapped in #ifdef DEPLOYMENT to issue a warning – so when building it I know absolutely that the code has been in fact compiled into the binary:

#warning Using Deployment Push Notification


I finally figured out weakSelf and strongSelf

One problem with using blocks and asynchronous dispatch is that you can get into a retain cycle – the block can retain ‘self’, sometimes in mysterious ways. For instance, if you reference an ivar directly, what appears in the code is ‘theIvar’, the compiler generates ‘self->theIvar’. Thus, ‘self’, as a strong variable, is retained, and the queue retains the block, and the object retains the queue.

Apple recommends first assigning ‘self’ into a weak automatic variable, then referencing that in a block (see 1). Since the block captures the variable along with its decorators (i.e. weak qualifier), there is no strong reference to ‘self’, and the object can get dealloced, and at that moment the weak captured variable turns to nil.

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
[weakSelf doSomething];
} );

Thinking about this, it occurred to me that ‘weakSelf’ might turn to nil in the middle of ‘doSomething’, but after a few posts on the xcode list, I was given a reference to a clang document that explicitly states that any object within an expression is retained for the complete expression, and only released thereafter (see 2). Whew!

But how about:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
[weakSelf doSomething];
[weakSelf doSomethingElse];
} );

Well, in this case, its possible for ‘weakSelf’ to be non-nil for the first method, but not for the second. Hmmm – the above is a simple example, most real code would get much more complex with other usages of ‘weakSelf’.

Apple calls this second example ‘non-trivial’ (see 1), and does what first seems like a bizarre set of steps: first create the ‘weakSelf’ object, then assign that to a ‘strongSelf’:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
__typeof__(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
} );

or in Swift:

dispatch_async(dispatch_get_main_queue()) { [weak self] in
if let strongSelf = self {
// See “Resolving Strong Reference Cycles for Closures” in The Swift Programming Language

I looked and looked at this trying to reason it out (guess I’m just slow). Finally, the light bulb lit, and I figured it out! When the block runs, it’s only captured ‘weakSelf’. At the instant the block starts up, ‘weakSelf’ is either ‘self’, or it’s nil. Your code (as Apple’s example does) can test to see if ‘strongSelf’ is set, and if so you can use ‘strongSelf->theIvar’ or the more normal ‘strongSelf.someProperty’ (the latter works fine with nil messaging, the former will crash if ‘strongSelf’ is nil).

If ‘weakSelf’ is equal to ‘self’, then ‘strongSelf’ retains it, and it stays retained until the block returns, when its released. It’s all or nothing.

I felt really good finally getting this, and its making my coding of blocks much easier.


If you’re puzzled by the use of __typeof__(self), it’s a non-standard clang macro that turns into the class of the parenthesized object, and was taken from GCC. The nice thing about using it is that you can make this line a Code Snippet (mine is called ‘WeakSelf’), and you don’t have to continually adjust the class type.

1) “Programming With ARC Release Notes, search for “For non-trivial cycles, however, you should use”

2) :

For __weak objects, the current pointee is retained and then released at the end of the current full-expression. This must execute atomically with respect to assignments and to the final release of the pointee.

NSOperation-WebFetches-MadeEasy now FastEasyConcurrentWebFetches

After reading the latest Apple Guides on NSOperation and Concurrency, I updated NSOperation-WebFetches-MadeEasy to use normal NSOperations. It simplified the code for sure. But then I asked myself why I was still using NSOperation and NSOperationQueue, and not GCD alone.

Since this established project has NSOperation in its title, I didn’t feel right in just updating it to GCD, so I cloned it to FastEasyConcurrentWebFetches and have now pushed that code up.

The big difference is that now is that most everything uses blocks and GCD. It turns out you can add a NSRunLoop to a block, and get the same ability to “sleep” awaiting messages as you do with NSOperation.

Screen Shot 2013-04-23 at 4.15.15 PM

This code will be the basis of a library I’m doing for my current employer, so it will get regular updates (as did NSOperation-WebFetches-MadeEasy), as bugs or other issues become evident.


AppScreenShotSomeone requested an algorithm to extract email addresses from a random chunk of text. It so happens that I had tripped on a site that evaluates regular expressions to verify if a string is in fact a valid email address against a huge list of both legal and illegal addresses. It’s truly amazing what strings are in fact legal!

I used what is now the second best algorithm for the Lot18 wine app, and so I wanted to see if this regex could be applied to a large text file with embedded addresses: it turned out the regex I had been using did not work for this purpose, but the current (as of 4/1/2013) best performer did.

However, neither regex handles “mailbox” detection as defined in RFC6068. Mailboxes look like “Joe Smith at IBM” <>. Since the “name” portion of the mailbox usually has important information contained in it, and wanted to see if I could find a reasonable algorithm to add it to the detector, a task I did in fact complete, and is open sourced on github as EmailAddressFinder.

But reading all the RFCs lead me to yet another email related issue, which is recovering “mailto” links within HTML source. In the end this turned out to be a much easier and elegant task, as the format of mailto links is quite regular. I had a bit of time recently and was able to add a mailto extractor to this project.

The only other addition to this project I can think of would be to provide a merged search: first detect the mailto tags and remove those from the original string, then secondly harvest the remaining text for other addresses. Most likely any given string would only contain one or the other, so I’m not doing anything until someone asks for it.

PS: if you end up using this it would be great if you could give the StackOverflow post an up-arrow.