Objective-C Coding Standards? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I've been teaching myself Objective-C for about 6 months and like using the language a lot. H开发者_JAVA百科owever I haven't found any good coding standards, so the code I write always ends up looking like an inconsistent mess.

Things like naming conventions carry over just fine, but spacing, indentation and the (impossible?) 80 character line-width aren't working out so well.

What conventions do you use with Objective-C?

Here is a small example of something that isn't working:

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    if ((self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil])) {

        self.navigationItem.leftBarButtonItem = 
        [[[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemCancel
                                                       target:self.parentViewController 
                                                       action:@selector(done:)] autorelease];

        NSString* units = [[NSString alloc] initWithFormat:@"%@", @"oz"];
        NSString* optionOne = [[NSString alloc] initWithFormat:@"[%d%@] Calculate", 100, units];

        self.options = [[NSMutableArray alloc] initWithObjects: 
                        optionOne, 
                        @"Configure Portions", 
                        @"Configure Notifications",
                        @"Help",
                        nil];

        [units release];
        [optionOne release];
        [tableView reloadData];
    }
    return self;
}

---

Apple's coding guidelines can be found here: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

---

Great question, thanks for asking it.

A few of my personal coding standards:

1. I don't stick to 80 characters, but I try to stay under 120 or so. Obj-C is a wordy language with "named" arguments, and Cocoa is an even wordier framework. I rarely need to edit code on a VT220.
2. I don't usually split long method calls with the ":" lined up vertically like Xcode wants you to do. I favor the traditional straight ahead, with lines wrapped as necessary, indented by one tab stop.
3. Where this becomes really unwieldy, I break out creation and use of objects over multiple lines. E.g. in the above, I'd likely create the options array on one line, and do [self setOptions:...] on the next one. This makes debugging simpler anyways.
4. I don't use dot notation for property access, since I find it hides behavior. I use the traditional [object property] notation.
5. I have never satisfactorily resolved the naming of ivars vs. locals. Xcode colors them differently, which is usually all I need, but the MSFT guy deep inside me still thinks instance scope prefixing is useful, e.g. m_ or at least _. But I usually don't, because it's ugly to look at. And goodness knows we Apple people hate ugly things. :)

(For what it's worth, in your example above, you can get an autoreleased string directly by using -[NSString stringWithFormat:...] instead of the alloc/init/release.)

---

Not that I use and/or like it, but Google's Objective-C Style Guide is worth a mention and a read.

---

This is probably the dissenting opinion around here but… I don't indent single lines at all, I turn on word-wrap. The advantage of this is that you can shrink/stretch your windows and the code always looks good, plus you don't have to waste any time messing around with newlines and tabs/spaces trying to make your code look acceptable.

---

This is another good source: (I am new so it wouldn't let me post two links in the same answer) http://cocoadevcentral.com/articles/000082.php (Cocoa Style for Obj C part 1 of 2)

part 2 is the same link but ending in 000083.php