The official KolesaTeam Objective-C style guide.

This style guide outlines the coding conventions for "Колёса | Крыша | Маркет" company. It is a slightly modified and supplemented version of the official raywenderlich.com Objective-C style guide.

Background

Here are some of the documents from Apple that informed the style guide. If something isn't mentioned here, it's probably covered in great detail in one of these:

• The Objective-C Programming Language
• Coding Guidelines for Cocoa
• iOS App Programming Guide

Table of Contents

• Language
• Code Organization
• Spacing
• Comments
• Naming
  • Underscores
  • Tests
• Methods
• Variables
• Collections
• Property Attributes
• Nullability
• Dot-Notation Syntax
• Literals
• Constants
• Enumerated Types
• Case Statements
• Private Properties
• Property Shadowing
• Booleans
• Conditionals
  • Ternary Operator
• Init Methods
• Class Constructor Methods
• CGRect Functions
• Golden Path
• Error handling
• Singletons
• Line Breaks
• Smiley Face
• Xcode Project
• Documentation

Language

US English should be used.

Preferred:

UIColor *myColor = UIColor.whiteColor;

Not Preferred:

UIColor *myColour = UIColor.whiteColor;

Code Organization

Use #pragma mark - to categorize methods in functional groupings and protocol/delegate implementations following this general structure.

#pragma mark - Lifecycle

- (instancetype)init {}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}

#pragma mark - Custom Accessors

- (void)setCustomProperty:(id)value {}
- (id)customProperty {}

#pragma mark - IBActions

- (IBAction)submitData:(id)sender {}

#pragma mark - Public

- (void)publicMethod {}

#pragma mark - Private

- (void)privateMethod {}

#pragma mark - Protocol conformance
#pragma mark - UITextFieldDelegate
#pragma mark - UITableViewDataSource
#pragma mark - UITableViewDelegate

#pragma mark - NSCopying

- (id)copyWithZone:(NSZone *)zone {}

#pragma mark - NSObject

- (NSString *)description {}

Spacing

• Indent using 4 spaces (This is a default in Xcode. You can verify it in Preferences → Text Editing → Indentation). Never indent with tabs.
• Method braces and other braces (if/else/switch/while etc.) always open on the same line as the statement but close on a new line.
• If the first option in a ternary operator is deliberately omitted there should not be a space between ? and :.

Preferred:

NSString *someString = someString ?: sotherString;

Not Preferred:

NSString *someString = someString ? : otherString;

• Any piece of documentation or comment should be preceded with a blank line. Except the cases when such a block immediately follows an opening curly brace.

Preferred:

if (user.isHappy) {
    // Do something
} else {
    // Do something else
}

Not Preferred:

if (user.isHappy)
{
    // Do something
}
else {
    // Do something else
}

• There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but often there should probably be new methods.
• Prefer using auto-synthesis. But if necessary, @synthesize and @dynamic should each be declared on new lines in the implementation.
• Colon-aligning method invocation should often be avoided. There are cases where a method signature may have >= 3 colons and colon-aligning makes the code more readable. Please do NOT however colon align methods containing blocks because Xcode's indenting makes it illegible.

Preferred:

// blocks are easily readable
[UIView animateWithDuration:1.0 animations:^{
    // something
} completion:^(BOOL finished) {
    // something
}];

Not Preferred:

// colon-aligning makes the block indentation hard to read
[UIView animateWithDuration:1.0
                 animations:^{
                     // something
                 }
                 completion:^(BOOL finished) {
                     // something
                 }];

• To boost readability, control flow blocks should be followed by a blank line. It is optional to have an empty line before the block.

Preferred:

// something
if (condition) {
    // Do something
}

// something

Not Preferred

// something
if (condition) {
    // Do something
}
// something

• Unless return is the only statement in the block it should always be preceded by a blank line.

Preferred:

­- (BOOL)isTrue {
    return YES;
}

­- (BOOL)isComplicated {
    BOOL retVal = NO;
    
    return retVal;
}

Not Preferred:

- (BOOL)isTrue {

    return YES;
}

­- (BOOL)isComplicated {
    BOOL retVal = NO;
    return retVal;
}

• In case of wrapping a method with blocks, the statements in the blocks should be indented by additional 4 spaces.

Preferred:

[[KKSomeClass sharedInstance] someLongMethod:KKSomeMethod
    parameters:parameters
    success:^(id obj) {
        // something
    } failure:^(id obj) {
        // something
    }];

Not Preferred:

[[KKSomeClass sharedInstance] someLongMethod:KKSomeMethod
    parameters:parameters
    success:^(id obj) {
    // something
    } failure:^(id obj) {
    // something
    }];

• When wrapping a method signature, which cannot be colon-aligned, all lines starting with the second one should be indented by 8 spaces.

Preferred:

­- (void)application:(UIApplication *)application
        performActionForShortcutItem:(UIApplicationShortcutItem *)shortcutItem
        completionHandler:(void (^)(BOOL))completionHandler {
    // something
}

Not Preferred:

­- (void)application:(UIApplication *)application
    performActionForShortcutItem:(UIApplicationShortcutItem *)shortcutItem
    completionHandler:(void (^)(BOOL))completionHandler {
    // something
}

Not Preferred:

­- (void)application:(UIApplication *)application
performActionForShortcutItem:(UIApplicationShortcutItem *)shortcutItem
completionHandler:(void (^)(BOOL))completionHandler {
    // something
}

• There should always be a blank line after @interface/@implementation and before @end.

Preferred:

@interface KKSomeClass : NSObject <KKSomeProtocol>

// something

@end

Preferred:

@implementation KKSomeClass

@synthesize someProperty = _someProperty;
// something

@end

Not Preferred:

@interface KKSomeClass : NSObject <KKSomeProtocol>
// something
@end

Not Preferred:

@implementation KKSomeClass

@synthesize someProperty = _someProperty;
// something
@end

• When declaring an id property or variable there should not be a space between id and <.

Preferred:

@interface SomeClass: NSObject

@property (strong, nonatomic, nonnull) id<SomeProtocol> someProperty;

@end

Not Preferred:

@interface SomeClass: NSObject

@property (strong, nonatomic, nonnull) id <SomeProtocol> someProperty;

@end

• In anonymous categories make sure to have a space between the class name and empty parentheses.

Preferred:

@interface SomeClass ()

// something

@end

Not Preferred:

@interface SomeClass()

// something

@end

Comments

When they are needed, comments should be used to explain why a particular piece of code does something. Any comments that are used must be kept up-to-date or deleted.

Block comments should generally be avoided, as code should be as self-documenting as possible, with only the need for intermittent, few-line explanations. Exception: This does not apply to those comments used to generate documentation.

Naming

Apple naming conventions should be adhered to wherever possible, especially those related to memory management rules (NARC).

Long, descriptive method and variable names are good.

Preferred:

UIButton *settingsButton;

Not Preferred:

UIButton *setBut;

A three or two letter prefix should always be used for class names and constants, however may be omitted for Core Data entity names.

Constants should be camel-case with all words capitalized and prefixed by the related class name for clarity.

Preferred:

static NSTimeInterval const RWTTutorialViewControllerNavigationFadeAnimationDuration = 0.3;

Not Preferred:

static NSTimeInterval const fadetime = 1.7;

A lowercased prefix should be used for method names in categories.

Preferred:

@interface NSObject (BFXConvertation)

- (BOOL)bfxIsString;

@end

Not Preferred:

@interface NSObject (BFXConvertation)

- (BOOL)BFXIsString;

@end

Not Preferred:

@interface NSObject (BFXConvertation)

- (BOOL)isString;

@end

Properties should be camel-case with the leading word being lowercase. Use auto-synthesis for properties rather than manual @synthesize statements unless you have good reason.

Preferred:

@interface SomeClass: NSObject

@property (strong, nonatomic) NSString *descriptiveVariableName;

@end

Not Preferred:

id varnm;

To avoid confusion one should not name a method starting with the words set and init unless it is either a setter or a constructor respectively. Specifically when a developer creates something from scratch they should name the method starting with the word setup.

Preferred:

- (void)setupLogoutButton {
    UIBarButtonItem *logoutItem = [[UIBarButtonItem alloc] initWithTitle:.......];
    [self.navigationItem setRightBarButtonItem:logoutItem animated:YES];
}

Not Preferred:

- (void)setLogoutButton {
    UIBarButtonItem *logoutItem = [[UIBarButtonItem alloc] initWithTitle:.......];
    [self.navigationItem setRightBarButtonItem:logoutItem animated:YES];
}

Not Preferred:

- (void)initLogoutButton {
    UIBarButtonItem *logoutItem = [[UIBarButtonItem alloc] initWithTitle:.......];
    [self.navigationItem setRightBarButtonItem:logoutItem animated:YES];
}

In situation when it is only necessary to configure an existing object, it is recommended to name a method starting with the word configure.

Preferred:

- (void)configureTableView {
    self.tableView.dataSource = self.dataProvider;
    [self.tableView registerNib:.......];
}

Not Preferred:

- (void)initTableView {
    self.tableView.dataSource = self.dataProvider;
    [self.tableView registerNib:.......];
}

Not Preferred:

- (void)setTableView {
    self.tableView.dataSource = self.dataProvider;
    [self.tableView registerNib:.......];
}

Likewise, a method responsible for providing an instance of UITableViewCell or UICollectionViewCell with needed data, should be named starting with the word configure.

Preferred:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:.......];
[cell configureWithSomeEntity:someEntity];

Not Preferred:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:.......];
[cell assignSomeEntity:someEntity];

Underscores

When using properties, instance variables should always be accessed and mutated using self.. This means that all properties will be visually distinct, as they will all be prefaced with self..

An exception to this: inside initializers, the backing instance variable (i.e. _variableName) should be used directly to avoid any potential side effects of the getters/setters.

Local variables should not contain underscores.

Tests

The following naming convention for tests helps better understand the behavior:

- (void)test<Method|Action|Whatever>_<success|failure>_<expected result="">

For Example:

- (void)testAuthorize_success_isTrue {
    // test statements
}

- (void)testDateRange_success_isWithinThreeDays {
    // test statements
}

- (void)testFoo_failure_isBar {
    // test statements
}

Methods

In method signatures, there should be a space after the method type (-/+ symbol). There should be a space between the method segments (matching Apple's style). Always include a keyword and be descriptive with the word before the argument which describes the argument.

The usage of the word "and" is reserved. It should not be used for multiple parameters as illustrated in the initWithWidth:height: example below.

Preferred:

- (void)setExampleText:(NSString *)text image:(UIImage *)image;
- (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;
- (id)viewWithTag:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;

Not Preferred:

-(void)setT:(NSString *)text i:(UIImage *)image;
- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;
- (id)taggedView:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;
- (instancetype)initWith:(int)width and:(int)height; // Never do this.

Variables

Variables should be named as descriptively as possible. Single letter variable names should be avoided except in for() loops.

Asterisks indicating pointers belong with the variable, e.g., NSString *text not NSString* text or NSString * text, except in the case of constants.

Private properties should be used in place of instance variables whenever possible. Although using instance variables is a valid way of doing things, by agreeing to prefer properties our code will be more consistent.

Direct access to instance variables that 'back' properties should be avoided except in initializer methods (init, initWithCoder:, etc…), dealloc methods and within custom setters and getters. For more information on using Accessor Methods in Initializer Methods and dealloc, see here.

Preferred:

@interface RWTTutorial : NSObject

@property (strong, nonatomic) NSString *tutorialName;

@end

Not Preferred:

@interface RWTTutorial : NSObject {
    NSString *tutorialName;
}

Collections

It is recommended to explicitly specify the type of elements in a colletion when possible.

Preferred:

@interface SomeClass: NSObject

@property (copy, nonatomic, nullable) NSArray<NSNumber *> *someArray;
@property (copy, nonatomic, nonnull) NSDictionary<NSString *, NSNumber *> *someDictionary;

@end

Not Preferred:

@interface SomeClass: NSObject

@property (copy, nonatomic, nullable) NSArray *someArray;
@property (copy, nonatomic, nonnull) NSDictionary *someDictionary;

@end

Property Attributes

Property attributes should be explicitly listed, and will help new programmers when reading the code. The order of properties should be: storage (weak, strong, assign, copy), atomicity (atomic, nonatomic), nullability (nullable, nonnull), access (readonly, readwrite), and getter/setter.

Preferred:

@interface SomeClass: NSObject

@property (weak, nonatomic) IBOutlet UIView *containerView;
@property (strong, nonatomic) SomeClass *someClassObject;
@property (copy, nonatomic, nonnull, readonly) NSArray *someArray;

@end

Not Preferred:

@interface SomeClass: NSObject

@property (nonatomic, weak) IBOutlet UIView *containerView;
@property (nonatomic) SomeClass *someClassObject;
@property (readonly, nonatomic, copy, nonnull) NSArray *someArray;

@end

Properties with mutable counterparts (e.g. NSString) should prefer copy instead of strong. Why? Even if you declared a property as NSString somebody might pass in an instance of an NSMutableString and then change it without you noticing that.

Preferred:

@interface SomeClass: NSObject

@property (copy, nonatomic) NSString *tutorialName;

@end

Not Preferred:

@interface SomeClass: NSObject

@property (strong, nonatomic) NSString *tutorialName;

@end

Nullability

When creating a new class, one should always explicitly specify nullability of its properties, method parameters and return values. For new properties in legacy code nullability should be omitted as it will trigger a compiler warning saying that nullability is not specified everywhere.

Dot-Notation Syntax

Dot syntax is purely a convenient wrapper around accessor method calls. When you use dot syntax, the property is still accessed or changed using getter and setter methods. Read more here

Dot-notation should always be used for accessing and mutating properties, as it makes code more concise. Bracket notation is preferred in all other instances.

Preferred:

NSInteger arrayCount = self.array.count;
view.backgroundColor = UIColor.orangeColor;
UIApplication.sharedApplication.delegate;

Not Preferred:

NSInteger arrayCount = [self.array count];
[view setBackgroundColor:[UIColor orangeColor]];
[UIApplication sharedApplication].delegate;

Literals

NSString, NSDictionary, NSArray, and NSNumber literals should be used whenever creating immutable instances of those objects. Pay special care that nil values can not be passed into NSArray and NSDictionary literals, as this will cause a crash.

Preferred:

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone": @"Kate", @"iPad": @"Kamal", @"Mobile Web": @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingStreetNumber = @10018;

Not Preferred:

NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingStreetNumber = [NSNumber numberWithInteger:10018];

Constants

Constants are preferred over in-line string literals or numbers, as they allow for easy reproduction of commonly used variables and can be quickly changed without the need for find and replace. Constants should be declared as static constants and not #defines unless explicitly being used as a macro.

Preferred:

static NSString * const RWTAboutViewControllerCompanyName = @"RayWenderlich.com";
static CGFloat const RWTImageThumbnailHeight = 50.0;

Not Preferred:

#define CompanyName @"RayWenderlich.com"
#define thumbnailHeight 2

Enumerated Types

When using enums, it is recommended to use the new fixed underlying type specification because it has stronger type checking and code completion. The SDK now includes a macro to facilitate and encourage use of fixed underlying types: NS_ENUM()

For Example:

typedef NS_ENUM(NSInteger, RWTLeftMenuTopItemType) {
    RWTLeftMenuTopItemMain,
    RWTLeftMenuTopItemShows,
    RWTLeftMenuTopItemSchedule
};

You can also make explicit value assignments (showing older k-style constant definition):

typedef NS_ENUM(NSInteger, RWTGlobalConstants) {
    RWTPinSizeMin = 1,
    RWTPinSizeMax = 5,
    RWTPinCountMin = 100,
    RWTPinCountMax = 500,
};

Older k-style constant definitions should be avoided unless writing CoreFoundation C code (unlikely).

Not Preferred:

enum GlobalConstants {
    kMaxPinSize = 5,
    kMaxPinCount = 500,
};

In enums 'undefined'/'missing' case should be the first one listed to make it evaluate to 0. If there is no such a case, then the first option should start from 1.

Preferred:

typedef NS_ENUM(NSInteger, FooType) {
    FooTypeUndefined,
    FooTypeFirst,
    FooTypeSecond
};

Not Preferred:

typedef NS_ENUM(NSInteger, FooType) {
    FooTypeFirst,
    FooTypeSecond,
    FooTypeUndefined
};

Preferred:

typedef NS_ENUM(NSInteger, FooType) {
    FooTypeFirst = 1,
    FooTypeSecond
};

Not Preferred:

typedef NS_ENUM(NSInteger, FooType) {
    FooTypeFirst,
    FooTypeSecond
};

Case Statements

Braces are not required for case statements, unless enforced by the complier. When a case contains more than one line, braces should be added.

switch (condition) {
    case 1:
        // ...
        break;
    case 2: {
        // ...
        // Multi-line example using braces
        break;
    }
    case 3:
        // ...
        break;
    default: 
        // ...
        break;
}

There are times when the same code can be used for multiple cases, and a fall-through should be used. A fall-through is the removal of the 'break' statement for a case thus allowing the flow of execution to pass to the next case value. A fall-through should be commented for coding clarity.

switch (condition) {
    case 1:
        // ** fall-through! **
    case 2:
        // code executed for values 1 and 2
        break;
    default: 
        // ...
        break;
}

When using an enumerated type for a switch, 'default' is not needed.

For Example:

RWTLeftMenuTopItemType menuType = RWTLeftMenuTopItemMain;

switch (menuType) {
    case RWTLeftMenuTopItemMain:
        // ...
        break;
    case RWTLeftMenuTopItemShows:
        // ...
        break;
    case RWTLeftMenuTopItemSchedule:
        // ...
        break;
}

Private Properties

Private properties should be declared in class extensions (anonymous categories) in the implementation file of a class. Named categories (such as RWTPrivate or private) should never be used unless extending another class. The Anonymous category can be shared/exposed for testing using the +Private.h file naming convention.

For Example:

@interface RWTDetailViewController ()

@property (strong, nonatomic) GADBannerView *googleAdView;
@property (strong, nonatomic) ADBannerView *iAdView;
@property (strong, nonatomic) UIWebView *adXWebView;

@end

Property Shadowing

If it is necessary to make a property readonly for other classes and readwrite inside the class, one shall to declare the property two times: as readonly in .h file and as readwrite in the class extension in .m file. All the other attributes of the property must be repeated.

For Example:

// In .h file
@interface MyClass: NSObject

@property (assign, nonatomic, readonly) NSUInteger viewsCount;

@end


// In .m file
@interface MyClass ()

@property (assign, nonatomic, readwrite) NSUInteger viewsCount;

@end

In situations when it is solely needed to initialize a property and never mutate it later, one should not shadow properties. In initializers we directly work with instance variables by means of underscore - _viewsCount, and this enables us to ignore readonly attribute.

Booleans

Objective-C uses YES and NO. Therefore true and false should only be used for CoreFoundation, C or C++ code. Since nil resolves to NO it is unnecessary to compare it in conditions. Never compare something directly to YES, because YES is defined to 1 and a BOOL can be up to 8 bits.

This allows for more consistency across files and greater visual clarity.

Preferred:

if (someObject) {}
if (![anotherObject boolValue]) {}

Not Preferred:

if (someObject == nil) {}
if ([anotherObject boolValue] == NO) {}
if (isAwesome == YES) {} // Never do this.
if (isAwesome == true) {} // Never do this.

If the name of a BOOL property is expressed as an adjective, the property can omit the “is” prefix but specifies the conventional name for the get accessor, for example:

@property (assign, getter=isEditable) BOOL editable;

Text and example taken from the Cocoa Naming Guidelines.

Conditionals

Conditional bodies should always use braces even when a conditional body could be written without braces (e.g., it is one line only) to prevent errors. These errors include adding a second line and expecting it to be part of the if-statement. Another, even more dangerous defect may happen where the line "inside" the if-statement is commented out, and the next line unwittingly becomes part of the if-statement. In addition, this style is more consistent with all other conditionals, and therefore more easily scannable.

Preferred:

if (!error) {
    return success;
}

Not Preferred:

if (!error)
    return success;

Not Preferred:

if (!error) return success;

Ternary Operator

The Ternary operator, ?: , should only be used when it increases clarity or code neatness. A single condition is usually all that should be evaluated. Evaluating multiple conditions is usually more understandable as an if statement, or refactored into instance variables. In general, the best use of the ternary operator is during assignment of a variable and deciding which value to use.

Non-boolean variables should be compared against something, and parentheses are added for improved readability. If the variable being compared is a boolean type, then no parentheses are needed.

Preferred:

NSInteger value = 5;
result = (value != 0) ? x : y;

BOOL isHorizontal = YES;
result = isHorizontal ? x : y;

Not Preferred:

result = a > b ? x = c > d ? c : d : y;

Init Methods

Init methods should follow the convention provided by Apple's generated code template. A return type of 'instancetype' should also be used instead of 'id'.

- (instancetype)init {
    self = [super init];
    if (self) {
        // ...
    }

    return self;
}

Class Constructor Methods

Where class constructor methods are used, these should always return type of 'instancetype' and never 'id'. This ensures the compiler correctly infers the result type.

@interface Airplane

+ (instancetype)airplaneWithType:(RWTAirplaneType)type;

@end

More information on instancetype can be found on NSHipster.com.

CGRect Functions

When accessing the x, y, width, or height of a CGRect, always use the CGGeometry functions instead of direct struct member access. From Apple's CGGeometry reference:

All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.

Preferred:

CGRect frame = self.view.frame;

CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);
CGRect frame = CGRectMake(0.0, 0.0, width, height);

Not Preferred:

CGRect frame = self.view.frame;

CGFloat x = frame.origin.x;
CGFloat y = frame.origin.y;
CGFloat width = frame.size.width;
CGFloat height = frame.size.height;
CGRect frame = (CGRect){ .origin = CGPointZero, .size = frame.size };

Golden Path

When coding with conditionals, the left hand margin of the code should be the "golden" or "happy" path. That is, don't nest if statements. Multiple return statements are OK.

Preferred:

- (void)someMethod {
    if (![someOther boolValue]) {
	    return;
    }

    // Do something important
}

Not Preferred:

- (void)someMethod {
    if ([someOther boolValue]) {
        // Do something important
    }
}

Error handling

When methods return an error parameter by reference, switch on the returned value, not the error variable.

Preferred:

NSError *error;
if (![self trySomethingWithError:&error]) {
    // Handle error
}

Not Preferred:

NSError *error;
[self trySomethingWithError:&error];
if (error) {
    // Handle error
}

Some of Apple’s APIs write garbage values to the error parameter (if non-NULL) in successful cases, so switching on the error can cause false negatives (and subsequently crash).

Singletons

Singleton objects should use a thread-safe pattern for creating their shared instance.

+ (instancetype)sharedInstance {
    static id sharedInstance = nil;

    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedInstance = [[self alloc] init];
    });

    return sharedInstance;
}

This will prevent possible and sometimes prolific crashes.

Line Breaks

• Do not have lines exceeding 100 characters. The option Page guide at column: 100 from Preferences → Text Editing → Editing can help in this.

• A long line of code should be carried on to the second line adhering to this style guide's Spacing section.

Preferred:

self.productsRequest = [[SKProductsRequest alloc] 
    initWithProductIdentifiers:productIdentifiers];

Not Preferred:

self.productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIdentifiers];

Smiley Face

It is very important to have the correct smile signifying the immense amount of happiness and excitement for the coding topic. The end square bracket is used because it represents the largest smile able to be captured using ascii art. A half-hearted smile is represented if an end parenthesis is used, and thus not preferred.

Preferred:

:]

Not Preferred:

:)

Xcode project

The physical files should be kept in sync with the Xcode project files in order to avoid file sprawl. Any Xcode groups created should be reflected by folders in the filesystem. Code should be grouped not only by type, but also by feature for greater clarity.

When possible, always turn on "Treat Warnings as Errors" in the target's Build Settings and enable as many additional warnings as possible. If you need to ignore a specific warning, use Clang's pragma feature.

Documentation

Documentation is to be written in Russian in the following format:

/**
 Short description.

 Detailed description.
 @code
     'Some code'
 @endcode
 @param 'Parameter name' 'Parameter description' (for methods only)
 @return 'Return value description' (for methods only)
 */

For one-line property/variable documentation, /// is preferred instead:

/// Description.

Xcode shortcut ⌥ Option + ⌘ Command + / generates the documentation boilerplate.

Other Objective-C Style Guides

If ours doesn't fit your tastes, have a look at some other style guides:

• Google
• Robots & Pencils
• New York Times
• Sam Soffes
• CocoaDevCentral
• Marcus Zarra