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



头文件#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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值