×

Objective-C编程规范以及建议

96
SuperMario_Nil 595a1b60 08f6 4beb 998f 2bf55e230555
2017.07.04 23:13* 字数 1594

本文记录一下Objective-C编程规范以及一些建议,可能后续会有些修改和补充,至于初衷是最近接手的项目中代码"有些"凌乱,所以整理了一篇,有一些来自网上,有一些是我平时的代码风格的吧~

Flag

方法声明和定义

-或者+和返回类型之间须使用一个空格,括号要同行并有一个空格

方法应该像这样:

- (void)doSomethingWithString:(NSString *)theString {
  ...
}

如果函数名字太长,可以用冒号对齐,像这样:

- (void)doSomethingWith:(GTMFoo *)theFoo
                   rect:(NSRect)theRect
               interval:(float)theInterval {
  ...
}

当第一个关键字比其它的短时,要保证下一行至少有4个空格的缩进,对齐关键字,像这样:

- (void)short:(GTMFoo *)theFoo
    longKeyword:(NSRect)theRect
    evenLongerKeyword:(float)theInterval {
  ...
}

方法调用

调用时所有参数应该在同一行:

[myObject doFooWith:arg1 name:arg2 error:arg3];

或者每行一个参数,以冒号对齐:

[myObject doFooWith:arg1
               name:arg2
              error:arg3];

方法定义与方法声明一样,当关键字的长度不足以以冒号对齐时,下一行都要以四个空格进行缩进

[myObj short:arg1
    longKeyword:arg2
    evenLongerKeyword:arg3];

不要使用下面的缩进风格:

[myObject doFooWith:arg1 name:arg2  // some lines with >1 arg
              error:arg3];

[myObject doFooWith:arg1
               name:arg2 error:arg3];

[myObject doFooWith:arg1
          name:arg2  // aligning keywords instead of colons
          error:arg3];

命名

对于易维护的代码而言,命名规则非常重要。Objective-C 的方法名往往十分长,但代码块读起来就像散文一样,不需要太多的代码注释

当编写纯粹的 Objective-C 代码时,我们基本遵守标准的 Objective-C naming rules,

文件名

扩展名 文件分类
.h C/C++/Objective-C 的头文件
.m Objective-C 实现文件
.mm Ojbective-C++ 的实现文件
.cc 纯 C++ 的实现文件
.c 纯C 的实现文件

类名

类名(以及类别、协议名)应首字母大写,并以驼峰格式分割单词

Objective-C 方法名

方法名应该以小写字母开头,并混合驼峰格式。每个具名参数也应该以小写字母开头
方法名应尽量读起来就像句子,这表示你应该选择与方法名连在一起读起来通顺的参数名。(例如,convertPoint:fromRect: 或 replaceCharactersInRange:withString:)。详情参见 Apple’s Guide to Naming Methods
第二个参数不要and

  • 正确: - (instancetype)initWithWidth:(float)width :(float)height;
  • 不好: - (id)initWithWidth:(float)width andHeight:(float)height;

变量名

应该使用驼峰命名法,变量名尽量能够代表其自身意思,尽量避免中英文混合命名,中英文混合命名是建议用'_'下划线分割中英文。
尽量避免如下命名方式

NSDictionary *d0 = [ACGPCacheCenter readFileAtSubDir: HSHomePageSubDirForAD];
NSDictionary *d2 = [ACGPCacheCenter readFileAtSubDir: HSHomePageSubDirForZX];
NSDictionary *d3 = [ACGPCacheCenter readFileAtSubDir: HSHPSubDirForEntry];
NSDictionary *d4 = [ACGPCacheCenter readFileAtSubDir: HSHPSubDirForCopywriting];

循环以及一些生命周期很短、很浅显易懂的变量可以放开要求,可以使用简单单字母等等变量名

常量名

常量名(如宏定义、枚举、静态局部变量等)应该以小写字母 k 开头,使用驼峰格式分隔单词,如:kInvalidHandle,kWritePerm


注释

建议注释不要过多,尽量能够做到代码自解释。与其给类型及变量起一个晦涩难懂的名字,再为它写注释,不如直接起一个有意义的名字

关于注释有以下几点建议:

.h 文件注释

.h 文件中 interface 前要加VVDocumenter注释,例如下面这个类,根据类名根本不知道哪个模块,做什么的。

@interface HSHPCopywritingCell : HSBaseCollectionViewCell

@end

应改成

/**
 首页模块-自选股cell
 */
@interface HSHPCopywritingCell : HSBaseCollectionViewCell

@end

之后在业务代码中遇到这个类,按住alt键鼠标点击类名就可以查看到类的Description如下:

属性以及成员变量注释

属性、成员变量、枚举类型的注释建议用 ///<进行注释

@property (nonatomic, strong) HSMarketIndexModel *USmodel;      ///< 美股指数model
@property (nonatomic, strong) HSMarketIndexModel *HKmodel;      ///< 港股指数model
@property (nonatomic, strong) HSMarketIndexView *indexView;     ///< 指数view

同样按住alt键鼠标点击类名也可以查看到类的Description,用/** 美股指数 */ 这种注释方式也可以看到Description,不过属性太多可能会不太美观

代码块注释

善用#pragma mark把代码进行分类,#pragma mark没有下划线,#pragma mark -有下划线分割

建议用如下类似代码块组织代码:

#pragma mark - ================ LifeCycle =================
- (void)viewDidLoad {
    [self configUI];
    ...
}
- (void) viewWillAppear:(BOOL)animated {
}...

- (void)configUI {
}

#pragma mark - ================ Public Methods =================

#pragma mark ==== 核心公开方法注释
- (void)somePublicMethod {
}

#pragma mark ==== 核心公开方法注释2
- (void)somePublicMethod2 {
}

#pragma mark - ================ Private Methods =================

#pragma mark ==== 核心私有方法注释
- (void)somePrivateMethod {
}

#pragma mark - ================ UITableView Delegate =================

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView { 
}...

#pragma mark - ================ Actions =================

- (void)someButtonClicked {
}

#pragma mark - ================ Getter and Setter =================

- (void)setModelArray:(NSMutableArray *)modelArray {
}

注意:代码块的顺序应该是由重要到不重要,Getter之类的不重要代码块要放在最后,确保别人打开你的类先映入眼帘的是有用的代码


其他

保持公共API简单

如果一个函数压根没必要公开,就不要这么做,属性也是一样,同时对方法进行合理的VVDocumenter注释,公开属性以及常量、枚举尽可能的用///<注释,除非特别特别简单的可以省略

关于警告

代码中遇到警告信息应该尽量解决掉,有一些可能是类型转换警告,有一些是无用的变量,代码永远不会被执行,已废弃的方法等等,有一点代码洁癖、对自己的代码要求严格是一件好事

关于废弃的代码

项目中遇到废弃的代码、没有用到的类(头文件)、注释掉的代码,除非一定要保留的都要尽量删掉,保留的写好注释,建议用TODO注释,保留的原因以及相关责任人,以便其他人接手不至于懵逼~


一些建议

定义常量时:多用类型常量,少用#define预处理指令

宏定义没有类型,有被重复定义风险,影响项目编译速度。
建议用

static NSString * const kConst = @"Hello";
static const CGFloat kWidth = 10.0;

代替:

#define kConst @"Hello"
#define kWidth 10.0

当定义对外公开的常量的时候,我们一般使用如下定义

//Test.h
extern NSString * const kClassNameconst;
//Test.m
NSString * const kClassNameconst = @"hello";

关于枚举

推荐使用NS_ENUM和NS_OPTIONS定义

typedef NS_ENUM(NSInteger,TestEnum) {
    MY_INT_CONST = 12345
};

typedef NS_OPTIONS(NSInteger, SelectType) {
    SelectA    = 0,
    SelectB    = 1 << 0,
    SelectC    = 1 << 1,
    SelectD    = 1 << 2
};

在枚举类型的switch语句中不要实现default分支,有一个好处是,当我们给枚举增加成员时,编译器就会提示开发者:switch语句并未处理所有的枚举

尽量使用简洁字面量语法

NSArray *animals = @[@"dog", @"pig", @"you"];
Dictionary *dict = @{@"animal":@"tiger", @"phone":@"iPhone 6"};

NSString *dog = animals[0];
NSString *iphone = dict[@"phone"];

属性的strong、copy

定义可变类型时不要用copy修饰,会留下崩溃隐患

@property (nonatomic, copy) NSMutableArray *mutableArrayOfCopy;   ///< 插入数据时会崩溃

一般NSString 以及NSArray等等不可变类型建议用copy修饰,用strong修饰也没错,不过要确定情景是否真的需要strong

结尾:

本文对Objective-C编码粗略规范以及一些浅显建议,欢迎大家一起补充完善,共同交流进步,维护增强项目代码的易读性,易扩展性,健壮性等等~

iOS开发相关
iOS开发相关
2.0万字 · 2.9万阅读 · 44人关注
Web note ad 1