Skip to content
This repository was archived by the owner on Feb 24, 2025. It is now read-only.

vineetchoudhary/iOS-Coding-Style-Guide

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 

Repository files navigation

Introduction

This style guide outlines the common coding conventions of the iOS Developers.

Table of Contents

Spacing

  • Indent must use 4 spaces. Be sure to set this preference in Xcode (defaults is 4 spaces).

  • Method braces and other braces (if/else/switch/while etc.) must open on the same line as the statement. Braces must close on a new line.

    For example: Objective-c

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

    Swift

    if user.isHappy == true {
        // Do something
    }
    else {
        // Do something else
    }
  • Separate imports from the rest of your file by 1 space. Optionally group imports if there are many (but try to have less dependencies). Include frameworks first.

    For example: Objective-c

    #import <AwesomeFramework/AwesomeFramework.h>
    #import <AnotherFramework/AnotherFramework.h>
    
    #import "SomeDependency.h"
    #import "SomeOtherDependency.h"
    
    @interface MyClass

    Swift

    import AwesomeFramework
    import AnotherFramework
    
    class MyViewController: UIViewController {
        // class stuff here
    }
  • In Objective-C, use one empty line between class extension and implementation in .m file.

    @interface MyClass()
    
    // Properties - empty line above and below
    
    @end
    
    @implementation MyClass
    
    // Body - empty line above and below
    
    @end
  • When using pragma marks leave 1 newline before and after.

    For example: Objective-c

    - (void)awakeFromNib {
        [super awakeFromNib];
        // something
    }
    
    #pragma mark - Config Cell
    
    - (void)configCell {
        // something
    }

    Swift

    override func awakeFromNib() {
       super.awakeFromNib()
       // somthing
    }
    
    // MARK: -  Config Cell
    
    func configCell() {
       //something
    }
  • Prefer using auto-synthesis. But if necessary, @synthesize and @dynamic must each be declared on new lines in the implementation.

  • 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.

  • When doing math use a single space between operators. Unless that operator is unary in which case don't use a space. For example:

    index = index + 1;
    index++;
    index += 1;
    index--;
  • 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.

    Good:

    objective-c

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

    swift

    UIView.animate(withDuration: 1.0, animations: {
        // something
    }, completion: { finished in
        // somthing
    })

    Bad:

    objective-c

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

    swift

    UIView.animate(withDuration: 1.0, 
                     animations: {
                        // something
                     }, completion: { finished in
                        // somthing
                     })

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.
  • Avoid block comments inline with code, as the code should be as self-documenting as possible. Exception: This does not apply to those comments used to generate documentation.

Developing....

References

Releases

No releases published

Sponsor this project

 

Packages

No packages published
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy