iOS代码规范

iOS代码规范

代码规范
    遵循原则:见文知意、清晰简洁、无错。
包括:
命名规范
代码规范
注释规范
项目规范

1、命名规范

类名首字母大写,方法首字母小写,方法中的参数首字母小写,同时尽量让方法的命名读起来像一句话,能够传达出方法的意。
原则:见文知意。

1)类名命名

采用大驼峰法则,即每个单词的首字母采用大写字母。
格式:前缀+名字+类型
前缀:大写,例如GG,用于修饰
类型:用于表明类的范围的,继承NSObject的类可不写

例如:
GGDemoView:前缀:GG,名字:Demo,类型:View
2)变量命名

采用小驼峰法则,第一个单词的首字母小写,后面单词的首字母全部大写。

例如:name,passWord。
3)常量命名

采用大驼峰法则,前缀加小k。

例如:NSString *kPersonName = @”abc”;
4)宏命名

采用大驼峰法则。

例如:#define AppKey  @"1235"
5)方法命名

采用小驼峰法则,第一个单词的首字母小写,后面单词的首字母全部大写。同时,尽量让方法名读起来像是一句话,能够清晰的传达方法要表达的意思。
例如:

- (instancetype)initWithFrame:(CGRect)frame;
  • 取得某个对象,以名词作为方法的开头;
例如:
    - (UIImage *)imageName:(NSString *)name;
  • 表示执行某操作,以动词作为方法的开头,get、make、set等;
例如:
    - (void)setupData;
  • 如果方法有参数,每个参数前最好有参数提示;
例如:
    - (instancetype)init:(CGRect)frame; //糟糕的方法命名
    - (instancetype)initWithFrame:(CGRect)frame; //好的方法命名
  • 如果方法有多个参数,不需要用and连接;
例如:
    - (instancetype)initWithFrame:(CGRect)frame andTitle:(NSString *)title; //不是很好
    - (instancetype)initWithFrame:(CGRect)frame title:(NSString *)title; //好
  • 返回BOOL值在方法前加前缀ishas
例如:
    - (BOOL)isEqualToString:(NSString *)aString;

2、代码规范

原则:有条理,层次清晰

1)属性、变量的声明
  • 属性、变量声明
    属性声明格式:@property(nonatomic, 关键字) + 1空格 + 类型 + 1空格 + *名称;
    例如:
@property(nonatomic, strong) NSString *name;

特点:类型跟星号之间有一个空格,星号紧跟变量名称,括号内的参数列表,逗号紧跟前一个参数再空格接下一个参数。
注意:此格式适用于继承自NSObject类的类型,对于基本数据类型的属性/变量只是没有“*”的区别。

  • 属性的使用
    请使用self.的方式应用类的成员变量,不推荐使用_变量名的方式。
    例如:
    推荐使用self.的方式:
        self.tableView.delegate = self;
        self.tableView.dataSource = self;
        
    不推荐如下的方式:
        _tableView.delegate = self;
        _tableView.dataSource = self;
2)方法
  • 方法声明的规范
    格式:-/+ + 空格 (类型)方法名;
    特点:-/+与返回类型之间有个空格,参数的类型用括号括起,参数之间有一个空格。
例如:
  - (instancetype)initWithFrame:(CGRect)frame;
  - (instancetype)initWithFrame:(CGRect)frame type:(int)type;
  • 方法实现
    特点:除上面的2)方法声明的规范外,
    1)在方法的结尾处加一个空格,然后紧跟大括号“{”;
    2)方法与方法之间空一行。
例如:
  - (instancetype)initWithFrame:(CGRect)frame type:(int)type {
    
  }
  //方法与方法之间空一行
  - (void)viewDidLoad {
    [super viewDidLoad];
  }
3)变量与方法声明的位置

对于私有变量、私有方法的声明,请把它们放在.m文件中。区别是不是私有,原则就是这个变量或方法要不要在别的地方使用,若是不要,就不要在.h文件中声明了,在.h文件中声明的就是公开。

4)操作符前后用1个空格隔开。

例如:

推荐写法:
    NSString *str = @"123456";
    NSInteger num = 2;
    BOOL flage = num > 1;
    str = flage ? @"1" : @"0";
这样写程序没有对与错,只是给人感觉有点凌乱:
    NSString*str =@"123456";
    NSInteger num=2;
    BOOL flage=num>1;
    str = flage?@"1":@"0";
5)代码缩进

1)使用xcode默认缩进,即tab = 4space,快捷键:左缩进commend+[,右缩进commend+]
2)xcode也提供格式化功能,选中代码,快捷键:control+i

6)判断nilYES/NO

推荐写法:

if (someObject) { ... }
if (!someObject) { ... }

避免如下写:

if (someObject == YES) { ...}
if (someObject != nil) { ...}

理由:if (someObject == YES)容易误写成赋值语句, if (someObject)写法也很简洁。

7)可变类型的变量要初始化

对于mutale类型的成员变量,如NSMutableArrayNSMutableDicyionary,先要完成初始化,再使用,没有初始化的话这个变量是为nil的。

8)block

使用block块,要弱引用对象,避免循环引用。使用关键字__weak__block__block可以修饰对象也可修饰基础数据类型的变量,__weak只能修饰对象。
规范写法如下:

__weak typeof(self) weakSelf = self;
myObj.myBlock =  ^{
    __strong typeof(self) strongSelf = weakSelf;
    if (strongSelf) {
        [strongSelf doSomething]; // strongSelf != nil
        // preemption, strongSelf still not nil
        [strongSelf doSomethingElse]; // strongSelf != nil
    }       
    else {
        // Probably nothing...
        return;
    }
};
9)移除通知

注册了observer,记得移除它,不限移除时间,但要保证在对象销毁前移除它,建议在dealloc方法中将observer移除。

10)避免硬编码

死值每次修改的时候容易被遗忘,也不方便查找、修改,另外仅仅看到一个数字,完全不知道这个数字代表的意义。可以采用动态获取,定义枚举、定义常量(知道含义)的方式。
例如:

-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return 2; //应尽量避免使用具体的数值,除非是很明确的情况下
}   

-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return self.array.count; //这种方式比写具体值方便多了。
}   
11)对象判空(nil)处理

对于外部传过的参数(特指对象)建议先进行空判断,避免不必要的错误,尤其是跟网络相关的数据(有可能json解析出来为空)。
提示:NSArray、NSDictionary类型的对象是不能添加nil数据的。

3、注释规范

注释方法有单行多行注释,按需求选择。单行注释的快捷键:commend+/。

1)变量注释
2)方法注释

方法定义必须注释清楚用途、入参出参含义、要求,建议使用VVdocumenter插件;
备注:xcode 8以后,会发现常用的注释插件VVdocumenter无法使用了。其实它是被Apple采纳了,融合到了xcode中了。快捷键:option+commend+/。(注意:光标要位于具体的方法处才有效)

3)类描述

类名最好能描述清楚自身是干什么用的,在头文件的注释中增加一行描述;

4)pragma mark

代码要按功能模块分块,用#pragma mark – name进行分组;

4、项目规范

1)项目的目录结构

一个合理的目录结构首先应该是清晰的,让人一眼看上去就能大概了解目录的职责,且容易应对新的变化。
在我们的项目中主目录按照模块分类,内目录按业务分类的方式。我们在xcode看到了目录结构,也要保证文件在磁盘中的存储结构也是如此的,方便查找、也方便管理。例如,在xcode创建了一个model目录,当向model目录中添加文件时,确保文件的存储位置是在model这个文件夹下。

2) 项目文件命名规范

采用大驼峰法则。但是不限使用中文标注,中文标注建议用小括号括起来。

例如:Tools(工具)
3)操作上的建议

1)按照目录层次来放置文件,建立子目录。

--养成一个良好的编程习惯 --

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,875评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,569评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,475评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,459评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,537评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,563评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,580评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,326评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,773评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,086评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,252评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,921评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,566评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,190评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,435评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,129评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,125评论 2 352

推荐阅读更多精彩内容