iKy1e | iOS Developer

farley:

I wish I could take credit for this but I can’t. Got this from an arstechnica.com forum posting from way back in June of 2010.

The forum poster’s moniker is The Real Blastdoor. Please join me in thanking him for this, because it is absolutely pure gold. Additionally, each and every word is true.

---

The Apple haters’ stages of grief go something like this:

1. Predict failure of new Apple product
2. Attribute early success of new Apple product to rabid fanbois affected by the reality distortion field
3. Attribute longer term success of product to stupidity of consumers
4. Purchase previously scorned product for stupid relatives so they stop bothering you to help support the open source version of Apple product sold by Super Lucky Technology Extreme Inc. that you convinced them to buy
5. Purchase previously scorned product for yourself just to see what all the fuss is about
6. Admit that you now own and use the product, but complain about the product’s lack of SD card slot on random Internet forum
7. Forget prior criticism of product, claim that it was revolutionary and an example of how Apple used to be really innovative, but has now lost its edge

Rinse and repeat
Author: The Real Blastdoor on Tue Jun 01, 2010 8:05 am

So true!

boredzo:

Not all of this is applicable to Cocoa and Cocoa Touch development (good luck not using the heap), but so much of it is. I recommend reading the whole thing, but here are some highlights translated to Objective-C and its environs:

Rule 2 (routine checking)

• All code shall always be compiled with all compiler warnings enabled at the highest warning level available, with no errors or warnings resulting.
• All code shall further be verified with a JPL approved state-of-the-art static source code analyzer, with no errors or warnings resulting. …

… The rule of zero warnings applies even in cases where the compiler or the static analyzer gives an erroneous warning. If the compiler or the static analyzer gets confused, the code causing the confusion should be rewritten so that it becomes more clearly valid. Many developers have been caught in the assumption that a tool warning was false, only to realize much later that the message was in fact valid for less obvious reasons. …

Raise your hand if you’ve heard the sentence “it’s a false positive, ignore it” before.

Rule 7 (thread safety)

• Task synchronization shall not be performed through the use of task delays.

Specifically the use of task delays has been the cause of race conditions that have jeopardized the safety of spacecraft. The use of a task delay for task synchronization requires a guess of how long certain actions will take. If the guess is wrong, havoc, including deadlock, can be the result.

In Cocoa/Cocoa Touch, this means that you should avoid using performSelector:withObject:afterDelay: (or sleep, usleep, nanosleep, +[NSThread sleepForTimeInterval:], -[NSRunLoop runUntilDate:], etc.) to try to “fix” a bug. Occasionally it fixes something. Often it breaks something else. And often it doesn’t fix the original problem.

For instance, an area of memory above the stack limit allocated to each task should be reserved as a safety margin, and filled with a fixed and uncommon bit-pattern.

On the Mac, you can do this with the malloc environment variables and/or GuardMalloc.

Rule 15 (checking parameter values)

• The validity of function parameters shall be checked at the start of each public function.
• The validity of function parameters to other functions shall be checked by either the function called or by the calling function.

Foundation provides NSParameterAssert for this purpose. In Objective-C, what this document calls a “public function” will generally be a method you’ve declared in the @interface in your class’s header file, whereas other functions are methods that you haven’t declared there. In other words, the class should trust itself to give itself good input, but not other classes.

Test cases are a good way to exercise these assertions: Intentionally send messages to the class, or instances of it, with bad input, knowing that if the assertion fails (an exception is thrown), the test will fail. If that doesn’t happen, it may indicate that the bad input would spread deeper into the class/object in a real run, which could be causing a problem your users are seeing (or will see).

Rule 25

• Functions should be no longer than 60 lines of text and define no more than 6 parameters.

This is especially true of C functions, since there’s nothing to label the parameters at the call site, but it’s a good rule for Objective-C, as well. If a single message contains more than, let’s say, 4 arguments, I recommend building an object around that message instead. Turn the arguments, particularly any that are optional, into properties.

Such objects will probably help you clarify other aspects of your design while you’re at it.

How to code to space craft levels of safety.