首页 >iOS开发

提升自己逼格的编程之美之代码规范

2017-01-05 05:43 编辑: AllanHou 分类:iOS开发 来源:君赏投稿

77.png

原文

提升自己逼格的编程之美之代码规范

头文件#import的顺序(商量)

写法模板

#import <系统库>

#import <第三方库>

#import “其他类”

尽量按照先系统类 第三方类 自己写的类顺序导入 中间不能有空格

建议的写法

1.png ? ?

不建议的写法

2.png

@Class的写法

写法模板:@class class1, class2;

建议的写法

3.png ? ?

不建议的写法

4.png ? ?

@Interface的写法

写法模板

@interface 类名 : 父类 <协议1, 2="">

@interface和类名中间一个空格

类名后紧跟:之后空格加上父类协议之间用,空格分割

建议的写法

5.png

不建议的写法

6.png ? ?

@protocol的写法

写法的模板

@protocol 协议的名称 <协议1, 2="">

@potocol和协议的名称有空格 协议的名称和其他协议有空格 其他协议之间有空格

建议的写法

7.png ? ?

不建议的写法

8.png ? ?

@property的写法

@property (关键词, 关键词) 类 *变量名称;

关键词用,空格分割 类前后空格

正确写法

9.png ? ?

不建议的写法

10.png

@property关键词的使用

对象?strong

基本变量assign

XIB控件 代理?weak

字符串和block使用?copy

对于一些弱引用对象使用weak

对于需要赋值内存对象?copy

h头文件方法写法

写法模板

@interface

方法的参数在一排显示

方法之间保留一行

第一个方法和@interface保留空行

最后一个方法和@end保留空行

建议的写法

11.png ? ?

错误写法

12.png ? ?

声明const的字符串

开头用k标识

推荐k+模板名字首字母大写+作用名称 防止和其他的重复

比如:CartViewModel类需要声明更新购物车列表的通知

kCVMNoticationUpdateCartList

如果是声明Cell的重用字符

k+cell的名称+identifier

比如: GBHomeItemTableViewCell的标识符

kGBHomeItemTableViewCellIdentifier

Const声明字符串位置

如果是需要声明在h里面让其他的类用到需要在h声明m实现

声明

13.png ? ?

实现

14.png

对于如果导入是UIKit类就使用UIKIT_EXTERN?如果是Founction使用关键词FOUNDATION_EXTERN

如果只在本类使用只用写实现 不用写声明。

方法尽量控制最多五十行

一个方法内部最多五十行 如果超过就精简代码 就分开方法写

方便之后进行热修复 代码重构

注释一定要写

自己管理的类一定注释属性用途 方法的用途 参数的说明

属性如果设置默认值 一定注明默认值是什么

如果方法内部存在逻辑判断 方法跳转 一定注释判断用法 方法跳转用法

除了初始化操作

其他声明变量 赋值 判断 应该注明注释用途

注释的写法

Class类注释

111.png ? ?

property属性的注释

112.png ? ?

方法的注释

如果有返回值 请加上return

113.png ? ?

局部变量和全局变量注释

114.png? ??

Block注释

115.png? ??

NSUM的注释

116.png

不允许外接修改的属性要设置readonly

大家平时设置属性默认是可读可写 但是这样容易对于别人造成误解 以为可以赋值

对于只能获取的属性 一定写readonly

正确的写法

117.png? ??

错误的写法

118.png ? ?

头文件引入的其他类 要使用@class

头文件引入的类使用@class声明不实用#import引入

可以防止互相引入 编译失败 不容易查找的BUG

造成的缺点

m文件还要#import 其他类调用这个类属性也要#import对应的类

综合来说宁愿自己多操作 也要防止这种循环引入的BUG的出现

建议的写法

119.png ? ?

不建议写法

120.png ? ?

pragma mark的使用

对于属性的不同作用 比如设置颜色的 设置字体的 设置其他样式 的可以进行分组

对于方法的作用分类 比如添加功能 删除功能的

对于其他的代理方法 Get Set方法 Init初始化方法

建议的写法

1111.png ? ?

BOOL类型属性的声明

属性set不要带is get要带is

建议写法

1112.png ? ?

不建议写法

1113.png ? ?

方法命名的规范

不能用init set 开头进行命名

如果不是写初始化方法不要用init进行开头

如果不是属性的set方法不要用set作为方法的前缀

{}的写法

建议的写法

1122.png ? ?

不建议的写法

1121.png ? ?

计算符号两边要有空格

比如 + - * / =等运算符左右有空格

建议的写法

21.png ? ?

不建议的写法

22.png ? ?

控件命名的规范

对于命名一定不要简写 那篇很长的单词 但是一些单词就是简写的除外 比如WTO RMB

UILabel结尾加上Label;

UIImageView结尾记上ImageView

等等让其他的编程人员看名字就知道变量的用法 和属于什么控件

建议的写法

23.png? ??

不建议的写法

24.png ? ?

if判断里面的条件要提取出来

对于if里面很多的判断条件 要提取出来 方便之后进行断点测试

建议的写法

31.png ? ?

不建议的写法

32.png ? ?

enum的定义

对于归属所在的enum 要写在对应的类

我们现在就全部enum放在一个文件 觉得和苹果的编码规范违背 并且分离代码有点麻烦

使用NS_ENUM进行定义

建议的写法

1.png ? ?

不建议的写法

2.png ? ?

对于初始化一定要使用类对应的初始化方法

比如UIView的对应初始化方法为

3.png ? ?

UIViewController对应的为

4.png ? ?

防止初始化用init new等没经过系统进行设置一些默认的属性 造成bug

对于声明NSString const要对适应对应的模块

比如系统的 NSNotificationName

5.png ? ?

建议的写法

6.png ? ?

不建议的写法

7.png ? ?

对于#define宏命名

单词全部的大写 单词之间用_分割

建议的写法

8.png ? ?

不建议的写法

9.png ? ?

对象调用方法要留空格

建议的写法

11.png ? ?

不建议的写法

12.png ? ?

对于只在m内部声明的const 需要添加static

这个我觉得可以不加 但是无法看到苹果的实现 所以不知道苹果的规范怎么写的

建议写法

13.png? ??

不建议的写法

14.png ? ?

对于局部的变量尽量的初始化

局部的变量要初始化 属性有默认的值 所以我们不必须对于属性进行初始化

我之前遇到的一个BUG就是int类型没有初始化给我默认Nan造成崩溃

建议的写法

15.png

不建议的写法

16.png ? ?

对于一些对象判断是否赋值可以不进行初始化 但是对于一定不会为nil要进行初始化

变量名的规范

一定要使用驼峰的命名

建议的写法

21.png ? ?

不建议的写法

22.png

对于属性的赋值

不要直接调用set方法

建议的写法

000.png

不建议的写法

000.png ? ?

对于NS_OPTIONS类型多个值用|连接不能用+

建议的写法

01.png

不建议的写法

02.png ? ?

block的命名规范

之前研究过很多的第三方的命名 对于苹果官方的没找到

有CallBack结尾 Complete结尾 Block结尾 还有CompletionHandle结尾的

我看到苹果很多的结尾都是用CompletionHandle结尾

大部分命名是Block我们按照Block命名

建议的写法

03.png

错误写法

04.png ? ?

使用NSUserDefaults要先创建

因为我们用到NSUserDefaults无非是保存和读取 事先的创建一个对象 可以精简代码

当执行方法很多 用变量替换

建议的写法

05.png ? ?

不建议的写法

06.png ? ?

尽量少在initialize load方法做一些初始化的事情

影响程序的启动

建议的做法

07.png ? ?

不建议的做法

08.png ? ?

通知的移除

通知在dealloc要使用移除对象监听的方法

建议的写法

001.png ? ?

不建议的写法

002.png ? ?

判断不要放在一行

判断放在一行也是可以的 但是我们还是要求正规一些 毕竟注明Apple的goto BUG

建议的写法

003.png ? ?

不建议的写法

004.png

对于我们取值和存值的key要定义一下

定义一下key 方便我们使用 并且方便之后改名字

建议的写法

005.png ? ?

不建议的写法

006.png

方法的参数连接不能有空格

建议的写法

aa.png ? ?

不建议的写法

aaa.png ? ?

对于block的循环引用使用weakify 和strongify

建议的写法

b.png ? ?

不建议的写法

bb.png ? ?

布局和设置约束的方法选择

可以实现GBInitViewProtocol协议 执行对应的方法

建议的写法

c.png

有利于其他人很方便查找当前界面布局和添加试图的位置

属性要尽量使用懒加载

我们一个界面有很多控件 利用懒加载可以美化代码

所有的懒加载放在Getter的mark的下面

建议的写法

a.png ? ?

推荐的界面框架

所有界面的控件元素独立到另外的UIView

UIViewController只负责跳转界面

新建UIView负责界面的显示

VIewModel负责数据的请求和解析

APi负责请求

model负责后台数据解析

other 负责样式和其他处理

多使用字面量

字符串 @””

a1.png ? ?

NSNumber @()

a2.png ? ?

字典 @{}

a3.png ? ?

数组 @[]

a4.png ? ?

字典和数组的取值和存值

多用类型常量 少用#define

建议的写法

b1.png ? ?

不建议的写法

b2.png ? ?

对于一些状态 选项的使用枚举

尽量少用根据数字判断状态少用字符串 数字判断状态

建议的写法

b3.png ? ?

不建议的写法

b4.png ? ?

多使用类族

比如我们需要创建一个类 有多个样式

b5.png ? ?

ZHCustomRedView

b6.png ? ?

ZHCustomWhiteView

b7.png

类名加上前缀避免冲突

因为团队的合作 可能会出现大家想到一样的名字或者添加第三方库引入和第三方库名字一样

尽量加上前缀。

如果只针对工程就使用工程的缩写

比如自己个人的第三方库就加上自己名字或者昵称的缩写

建议的写法

c1.png ? ?

不建议的写法

c2.png ? ?

提供全能的初始化方法

对于初始化参数有很多 但是不是一定全部使用的可以提供多个初始化方法

建议的写法

c3.png ? ?

不建议的写法

c4.png ? ?

实现Description方便调试

这个不推荐自己手写 可以使用Xcode插件自动生成 属性越多会加重手写代码的长度

尽可能使用不可变的对象

对于OC存在很多可变的对象 比如NSMutableString NSMutableArray NSMutableDictionary等等

对于一些不允许改变的直接使用不可变对象

可以节省对象开支 还可以防止别人修改数据造成bug

建议的写法

c5.png ? ?

不建议的写法

c6.png ? ?

如果建议的使用Block和代理

我觉得代理可以用在写控件需要数据源赋值 和一些事件回调的时候使用

我查阅了苹果的block基本上都是执行一个时间 需要异步回调就使用block

如果没有主动执行动作 而是监听异步的回调 建议用代理

建议的写法

c7.png ? ?

不建议的写法

c8.png ? ?

记得Dealloc记得释放

记得在Dealloc释放注册的通知和KVO的监听

不释放容易造成内存释放崩溃

养成习惯把按照方法功能到分类里面

对于一些有按照功能类型的方法划分在一个分类里面 分类和之前类写在同一个文件

建议的写法

d1.png ? ?

不建议的写法

d2.png ? ?

为第三方类添加分类添加前缀

比如为系统UIView添加分类Add的添加前缀

建议的写法

d3.png ? ?

不建议的写法

d4.png ? ?

尽量少在分类里面使用属性

假设我们分类有一个只读的字段 我们可以不使用属性 可以使用方法

建议的写法

d5.png ? ?

不建议的写法

d6.png ? ?

非要在自己类的分类添加读写的属性 可以用语法糖

可以利用主类的私有变量

建议的写法

d7.png

不建议的写法

d8.png ? ?

对于给第三方和系统的类非要添加属性 可以使用runtime。

对于一些自己不确定的可以使用try catch

对于不知道后台返回什么类型的 可以使用try catch

建议的写法

e1.png ? ?

因为OC是运行时语法 可能array不一定是NSArray类型的

不建议的写法

e2.png ? ?

如果后台返回list为字段 这段代码就崩溃了 可以使用try catch也可以用Model库 或者自己添加判断

使用dispatch_once来创建单例

建议的写法

e3.png ? ?

不建议的写法

e4.png ? ?

便利的写法

如果只需要便利数组和字典的写法用for in

建议的写法

e5.png ? ?

不建议的写法

e6.png ? ?

需要便利字典和数组的内容 并且需要索引用enumerator

建议的写法

e7.png ? ?

不建议的写法

e8.png

如果想进行缓存使用NSCache不要使用NSDictionary进行缓存

建议的写法

f1.png ? ?

不建议的写法

f2.png ? ?

尤达表达式

推荐:

f3.png ? ?

不推荐:

f4.png ? ?

nil 和 BOOL 检查

推荐

f5.png ? ?

不建议的写法

f6.png ? ?

黄金大道

建议的写法

121.png ? ?

不建议的写法

122.png ? ?

复杂的表达式

建议的写法

123.png ? ?

不建议的写法

124.png ? ?

三元运算符

推荐:

221.png

不推荐:

222.png ? ?

当三元运算符的第二个参数(if 分支)返回和条件语句中已经检查的对象一样的对象的时候,下面的表达方式更灵巧:

推荐:

223.png ? ?

不推荐:

224.png ? ?

错误处理

有些方法通通过参数返回 error 的引用,使用这样的方法时应当检查方法的返回值,而非 error 的引用。

推荐:

32.png ? ?

此外,一些苹果的 API 在成功的情况下会对 error 参数(如果它非 NULL)写入垃圾值(garbage values),所以如果检查 error 的值可能导致错误 (甚至崩溃)。

数组和字典最好指定元素的类型

建议的写法

33.png? ?

不建议的写法

34.png ? ?

数组和字典的元素垂直写

建议的写法

35.png ? ?

不建议写法

36.png

搜索CocoaChina微信公众号:CocoaChina
微信扫一扫
订阅每日移动开发及APP推广热点资讯
公众号:
CocoaChina
我要投稿   收藏文章
上一篇:如何用Xcode8解决多线程问题
我来说两句
发表评论
您还没有登录!请登录注册
所有评论(0

综合评论

相关帖子

sina weixin mail 回到顶部