In the event that a given source file is copied into another project, this ensures to a reasonable extent that the license is preserved and that original ownership is noted.

Open for debate: The size of the preamble could potentially be minimized to a single line.

By grouping imports into logical groups, it's easier to read and quickly understand what dependencies this source has with respect to the given sections of Three20.

By placing the Apple Frameworks at the bottom, we decrease the chances of import order mattering. Consider this example:

#import <Foundation/Foundation.h>

// UINavigator
#import "Three20UINavigator/TTURLNavigatorPattern.h"

Let's say that TTURLNavigatorPattern depended on Foundation.h for NSObject, but it didn't actually include Foundation.h within itself. If this is the only place that TTURLNavigatorPattern is imported, the project will build successfully right now. But if we then try to import only TTURLNavigatorPattern somewhere else, without placing Foundation.h above it, we'll get a build error.

This rationale is contrary to the above goal of reducing import order errors. The goal of placing TTGlobal* imports at the top of a logical group is to make it easy to absorb the set of imports used in any given group.

This guideline is subject to debate.

This will reduce incremental build times and make it clear as to which objects the given class legitimately depends on.

Due to the verboseness of Objective-C, the difference between 100 characters and 80 is quite noticeable. We're also not using strict 80 character terminals for development anymore. 100 was chosen due to the ability of laying out two source files side-by-side on the screen, while still seeing all code.

It is impossible to guarantee that everyone is using the same IDE with the same tab spacing. Also, Three20 frequently uses alignment to make code more readable. As such, we use spaces instead of tabs to guarantee that the code is always presented consistently.

This point is purely religious. Two spaces was chosen due to historical use, as well as the minimal amount of space it uses (compared to four spaces).

Three20 does, in fact, import the above frameworks in the precompiled header. However, the goal of Three20 is to be independent of precompiled headers if a developer ever needed to build a subset of Three20 without a precompiled header. For this reason, we must import frameworks as necessary.

In order to verify that you are doing this correctly, use the "Internal" build, which is a special internal build that does not use precompiled headers. A nice side effect of this is that if Internal builds, it's guaranteed to build in Debug and Release (the inverse is not strictly true).

Side note: Debug and Release Three20 builds both use a precompiled header to speed up compilation times of the library.

The inherited class file is sufficient because it will generally import the required frameworks.

Sometimes the inherited class file won't import all of the necessary frameworks. If this happens, import the frameworks, still keeping in mind the import order.

This will reduce header file dependencies and therefor improve incremental build times.

Class prefixing is a common practice for avoiding namespace conflicts.

This improves the readability of diffs if/when you change the protocols that this class imports. This also makes it easier to quickly read the set of implemented protocols.

Ivars should never be accessed directly from an outside class; this is what properties are for.

This makes it easy to differentiate between a property accessor (self.userInfo) and accessing a private ivar (_userInfo).

_ is a prefix instead of a suffix because it immediately narrows down autocompletion to private ivars when you type _. This is counter to Apple's recommendation of using _ as a suffix for private ivars.

This then transfers to property names, making it easy to begin typing a property name with only one keypress (no shift key involved).

With respect to acronyms, you should still use use a lowercase first letter. For example: _urlPath, instead of _URLPath.

This makes it easier to understand the contents of the class. Space the ivar names such that they align vertically in each logical group.

Delegates are generally much longer declarations and would otherwise throw off the alignment of the other ivars.

The alternative is atomic, which has potential performance implications that may be undesirable.

Don't depend on people's memory to recall what the default property access levels are. Unless you're 100% confident that 100% of people reading the code will remember the implicit access level, make it explicit.

This doesn't need much explaining. You either do this right, or you don't and suffer the memory hazards as a result.

These comment lines help bring focus to the start of a method better than simple whitespace. They also act as a bounds checker when writing long lines of code.

init and dealloc are two most common methods used in classes, and therefor should be the easiest to find.

See the Apple documentation on designated initializers for more details. Initializers should set self outside the if condition per the Apple Documentation.

If statements without curly braces will only run the next logical line. If you use a macro that expands to multiple lines of code that are also not wrapped in curly braces, this can lead to difficult-to-find bugs where only part of the logic in the macro is executed. In practice, we don't use many macros in Three20, so this is mostly a defensive coding strategy.