Skip to content
This repository has been archived by the owner on Jan 3, 2019. It is now read-only.

Code style guidelines

Jakub Suder edited this page Oct 10, 2013 · 4 revisions

General

  • don't commit commented out code unless you have a really good reason

  • prefer small, atomic commits - don't push commits that change two completely unrelated things

  • keep the code DRY

  • when you add a new class, add a small comment (1-2 sentences) above its @interface declaration that explains what this class does, e.g.:

    /*
     An image cell that displays the image clipped to a circle. Used for application icons on the applications list.
     */
  • when you add a new group in Xcode, add also a new matching subdirectory in the project directory and assign that directory to the group (see the "Path" entry in "Identity" section in the right sidebar when the group is selected in the file inspector)

  • though Xcode makes that rather hard and annoying, try to keep files and directories sorted by name in Xcode file inspector when you add new files or groups

Code formatting

  • indent code with 4 spaces

  • style for method declarations: one space after +/- and one space between method name parts, like this:

    - (NSString *)initWithNibName:(NSString *)name andOwner:(id)owner
  • always put braces on the new line for interface blocks, method bodies, if/else/foreach blocks etc.; one exception: put braces on the same line for block bodies. E.g.:

    if (foo)
    {
        ...
    }
    else
    {
        ...
    }
    
    [foo executeCommands:^{
        ...
    }];
  • always put braces around if/else code blocks, even if they only contain one statement, e.g.:

    if (!self.isVisible)
    {
        [self show];
    }
  • avoid lines longer than 120 characters - if necessary, use multiline method calls or declarations (with colons aligned below the first one) or extract method calls as independent statements, e.g.:

    // bad:
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(windowClosed:) name:HISendWindowDidClose object:nil];
    
    // good:
    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(windowClosed:)
                                                 name:HISendWindowDidClose
                                               object:nil];
    
    // bad:
    [self.navigationController pushViewController:[[HIApplicationRuntimeViewController alloc] initWithApplication:app] animated:YES];
    
    // good:
    HIApplicationRuntimeViewController *subview = [[HIApplicationRuntimeViewController alloc] initWithApplication:app];
    [self.navigationController pushViewController:subview animated:YES];

Naming

  • use HI prefix for class names
  • prefix instance variable names with underscores (e.g. NSArray *_transactionList;)
  • avoid one-letter variable names and abbreviations, like HIContact *c or NSButton *currBtn

ObjC style

  • if an instance variable has a public or private property declared, access it internally through the property whenever possible, e.g.:

    // bad:
    [_tableView delesectAll];
    
    // good:
    [self.tableView deselectAll];
  • always use the new syntax for array/dictionary literals, subscripting and boxing, e.g.:

    NSArray *a = @[@"Helvetica", @"Comic Sans"];
    NSDictionary *options = @{ @"size": @12.0 };
    return [NSFont fontWithName:a[1] size:options[@"size"]];
  • use string constants for notification names, entity names, dictionary keys etc.:

    static NSString * const HISendWindowDidClose = @"HISendWindowDidClose";
    
    [notificationCenter postNotificationName:HISendWindowDidClose object:self];
  • wrap all strings in code that will be displayed in the UI in NSLocalizedString:

    [field.cell setPlaceholderString:NSLocalizedString(@"First name", @"First name field placeholder")];
Clone this wiki locally