Never return early in OBJ-C about guides HOT 7 CLOSED

We have this rule in Ruby, in case you're looking for an internal precedent.

from guides.

Related: #49

from guides.

So guys, ehm. What's the take here?
(Sorry, doing some cleaning with older issues and PR's)

from guides.

@gfontenot @halogenandtoast @21x9 @theocalmes

from guides.

I agree with you for the most part, but I think there are a couple of situations that are unique to Objective-C where using multiple returns lead to much cleaner code. Custom init methods, for example, read better when you don't have to wrap the entire method in a conditional that checks to make sure self was initialized properly:

- (instancetype)initWithFoo:(Foo *)foo
{
    self = [super init];
    if (!self) return nil;

    _foo = foo;
    // more setup

    return self;
}

I've recently been having a debate about it with myself, but I think I'm liking the same pattern for lazily initialized objects:

- (Foo *)foo
{
    if (_foo) return _foo;

    _foo = [[Foo alloc] init];
    // set up foo

    return _foo;
}

The thing to note here is that the point of the early return isn't to return multiple objects. The point is to bail early if possible to avoid bloated conditionals. It should really only be used to catch exceptional cases, like when self hasn't been initialized properly. For example, I wouldn't use multiple returns inside -tableView:cellForRowAtIndexPath::

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell;
    switch (indexPath.row) {
        case RowThatRequiresSpecialCell:
            cell = [self helperMethodThatVendsACell];
            break;
        default:
            cell = [self helperMethodForBasicCell];
            break;
    }

    return cell;
}

from guides.

I personally prefer the conditionals inside an init, though I agree that there can be edge cases, where a simple return to kick out of the selector would be preferable, but that being said -> init is not one of them.

I agree about not doing so in cellForRow:. Btw, you'd wanna set cell to nil (since it's not a property). Best practices and etc. That being said, not sure if ARC is taking care of it, but I still tend to do so, old habit from high school C++.

from guides.

Under ARC, all pointer variables for Objective-C objects are set to nil by default. So you don't need to do that anymore.

Thanks for your input though. We'll continue to discuss internally, but I don't think we're going to make this change to our style guide right now.

from guides.