I was reading NYTimes Objective-C Style Guide which lists the coding conventions The New York Times’ iOS teams are following and reasons why they are recommended. It’s so far the most succinct and clearest description I’ve ever seen.

After reading this document, I think a good coding style is all based on 2 principles:

1. Readability

It’s nothing more than Naming and Formatting in this part. After all, team working is never about individuals’ preference. To think more about names of methods and variables and to write clear comments would help a lot for later development or maintenance.

Long, descriptive method and variable names are good.

Apart from following camel-case, they mentioned that by adding class name to variables, others could know what they really are immediately. For example,

UIButton *signUpButton;

As for formatting style, consistent spaces and indents are to make code base readable and to prevent creative developers from attacking formatting freaks. (I’m obviously joking.)

2. Stability

Before my first full-time job, I’ve never thought about stability. It’s mentioned in the document that no matter what, you MUST use braces for if/else to avoid any logical errors with unaware mistakes.

There is this convention (which is not listed in NY Times style guide) having me shocked the most — Always put constant before variable when you’re comparing them.

Imagine ignoring what veterans have suggested, we code like this

CGFloat signUpButtonHeight = 40.0f;
if (signUpButtonHeight == 10.0) {
    // do something
}

But accidentally missing one = in if condition, so now it becomes

CGFloat signUpButtonHeight = 40.0f;
if (signUpButtonHeight = 10.0) {
    // do something
}

In this case, not only signUpButtonHeight would be set to 10.0, the condition would also be executed, which is nothing as we expected.

However, if we’d have done it reversed like

CGFloat signUpButtonHeight = 40.0f;
if (10.0 == signUpButtonHeight) {
    // do something
}

It’s even not able to be compiled if we miss one =. Doesn’t it save tons of precious time of debugging?

There are also some principles for property, singleton, etc in the document. I highly suggest you to read it if you’re a newbie and you’re interested.

I also want to talk about Literal.

If you ever wrote Objective-C, you must have had this experience

Every time I’m initializing NSArray or NSDictionary, I have to use a long-ass method with bare readability and worry that fetching values may cause crashes because of the ending nil. Literal is totally an existence to save my life for this. I can see the relation between keys and values with one glance and never worry about that nil.

There are 4 immutable objects mentioned in the document

NSArray *nameArray = @[@"Brian", @"Matt", @"Chris", @"Alex"];
NSDictionary *productManagerDictionary = @{@"iPhone"     : @"Kate", 
                                           @"iPad"       : @"Kamal", 
                                           @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiteralBoolNumber = @YES;
NSNumber *buildingZIPCodeNumber = @10018;

Then I was thinking, what about mutable objects? After some tests, I got some solutions

/*
 * I only use abbreviation because of the length limit
 */
NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex"];
NSMutableArray *nameMArray = [NSMutableArray arrayWithArray:names];
NSDictionary *dict = @{@"iPhone"     : @"Kate", 
                       @"iPad"       : @"Kamal", 
                       @"Mobile Web" : @"Bill"}; 
NSMutableDictionary *mDict = [NSMutableDictionary dictionaryWithDictionary:dict];

Didn’t know that there is so much of coding style. I’ll just stop here. Will update if facing issues in other aspects.