IOS开发iOS开发

Objective-C编程规范以及建议

2017-07-04  本文已影响521人  SuperMario_Nil

本文记录一下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：

变量名

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

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编码粗略规范以及一些浅显建议，欢迎大家一起补充完善，共同交流进步，维护增强项目代码的易读性，易扩展性，健壮性等等~

上一篇下一篇

猜你喜欢

热点阅读