Perfect iOS Coding Style

Perfect coding style need to follow everyone for developing any kind of application, software. Its very important for coding.

Organization Style:

For methods functional groupings always use #pragma mark so that anyone easily understand the methods groupings and there similar works and easy to find any kind of methods.

#pragma mark - Lifecycle

- (instancetype)init {}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}

Imports

If there is more than one import statement, statements MUST be grouped together. Groups may be commented.

// Frameworks
#import <Social/Social.h>
#import <Accounts/Accounts.h>
#import <Fabric/Fabric.h>
#import <TwitterKit/TwitterKit.h>
#import <LineSDK/LineSDK.h>
// Models
#import "NSString+MD5.h"
#import "NSString+Categories.h"
// ViewControllers
#import "CPLoginViewController.h"
#import "LoginViewController.h"

Private Properties

Private properties should be declared in the implementation file.

Naming Style

There has some guidelines when naming variable, methods:

  • Use a suitable name for each variable and method.
  • Start the name with lowercase letter and capitalize the first letter of embedded words.
  • Boolean type variable and method name need to use is as a prefix.
  • Long method name are more expressive
  • If it is a notification, it should have notification in its name

Methods

  • Should be a space after the method type (-/+ symbol). There should be a space between the method segments.
Right:
- (void)setText:(NSString *)text image:(UIImage *)image;
Wrong:
-(void)setText:(NSString *)text image:(UIImage *)image;
-(void) setText:(NSString *) text image:(UIImage *) image;
  • When method returns an attribute of the receiver, name the method after the attribute. The use of “get” is unnecessary.
Right:
- (CGSize)cellSize;
Wrong:
- (CGSize)getCellSize;
  • Use keywords before all arguments
Right:
- (void)sendAction:(id)selector forAllCells:(BOOL)flag;
Wrong:
- (void)sendAction:(id)selector :(BOOL)flag;
  • Use four space for before each line in a method for code alignment
- (void)addMenu
{
float scale = 1.0;
if (IS_IPHONE_4_OR_LESS) {
scale = 0.85;
}else if(IS_IPHONE_5){
scale = 0.72;
}else if(IS_IPHONE_6){
scale = 0.62;
}else if(IS_IPHONE_6P){
scale = 0.58;
}
}

Comment

In code if need comments then its should be used to explain why a particular piece of code does something and anyone can understand why this method use in code. For example, why this method use. Block comments should generally be avoided, as code should be as self-documenting as possible, with only the need for intermittent, few-line explanations. Exception: This does not apply to those comments used to generate documentation.

Blocks Style

For blocks writing, we always follow which is easily readable. colon aligning makes the block very hard to read

Right:
[UIView animateWithDuration:1.0 animations:^{
// do something
} completion:^(BOOL finished) {
// do something
}];
Wrong:
[UIView animateWithDuration:1.0
animations:^{
// do something
}
completion:^(BOOL finished) {
// do something
}];

Singleton

Singleton objects should use a thread-safe pattern for creating their shared instance. This will prevent possible

+(instancetype)sharedSSOController {
static TDCSSOController* sharedController = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedController = [[self alloc] init];
});
return sharedController;
}

Conditionals

In conditional bodies must use braces even when a conditional body could be written without braces to prevent error. These errors include adding a second line and expecting it to be part of the if-statement. Another, even more dangerous defect can happen where the line inside the if-statement is commented out, and the next line unwittingly becomes part of the if-statement. In addition, this style is more consistent with all other conditionals, and therefore more easily scannable.

Right:
if (!error) {
return success;
}
Wrong:
if (!error)
return success;
or 
if (!error) return success;

Others

There has so many rules need to follow for a standard coding. The physical files should be kept in sync with the Xcode project files in order to avoid file sprawl. Any Xcode groups created should be reflected by folders in the filesystem. Code should be grouped not only by type, but also by feature for greater clarity.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.