前言
遵守规范也是让代码更清晰明了,易读,易用,易维护,可以更好的适应团队开发。自己看着也是赏心悦目,何乐而不为呢。
1.基本准则
1.1编写清晰
简单明了的命名最好,不要用单词的简写,尽量用单词的全称。可以看看苹果的API格式,仿照苹果的命名,尽量用英文,而不是拼音。
1.2一致性
比如方法名的功能类型的一致性,比如获取某些数据 - (NSString *)getName,- (NSString *)getAge 中的get;或者设置数据 - (void)setName,- (void)setAge 中的set。统一方法名可以让人一看这方法就知道是干什么用的,提升开发效率。
1.3驼峰原则
- 大驼峰原则:每个单词的首字母大写(UserNameTextField)
- 小驼峰原则:第一个单词首字母小写,其余都大写(userNameTextField)
2.命名规范
2.1类命名
类的命名是采用大驼峰原则,如
UserLoginViewController
在实际开发中,一般会在类名前面加个前缀:
OYUserLoginViewController
加统一前缀方法如下图:
设置完后,每次在创建类的时候会自动添加前缀。
User → 用户
Login → 登陆
ViewController → 控制器
这个类的用途就一目了然了
其他例子:OYUserModel,OYTitleView,OYNetManager。。。
应用级别的类名(需要在其他项目中用到的类),可以不使用前缀或者使用自定义前缀
即为:PhotoBrowser或者XXPhotoBrowser
2.2分类命名
UIView+OYFrame 或者 UIView+OYExtension
前者是对UIView这个类做的扩展,OY是前缀,Frame算是具体化功能,对Frame获取。比较清晰。
后者也是对UIView这个类扩展,但是并没有写明具体功能,可以在里面添加关于UIView的很多扩展。具体功能可以在.h文件里注释。文件较少易于管理。
二者的选择看个人喜好了
2.3方法命名
方法的命名是采用小驼峰的原则,如
- (XXModel *)modelWithDictionary:(NSDictionary *)dictionary;
此类命名可以模仿苹果提供的API,看见方法名大概可以猜出开是做什么的。注意参数名也是小驼峰式的。
代理方法仿照苹果API。
2.4变量命名
普通变量采用小驼峰原则,
NSInteger userCode;
成员变量要在前面需要加下划线'_'
@interface ViewController () {
NSString *_sex;
NSString *_birthday;
NSInteger _nameCount;
}
全局变量我一般在末尾加个下划线'_'
NSInteger userCode_;
2.5常量命名
常量(宏、枚举、全局常量、局部常量等)
1. k + 大驼峰 kUserCode
2. 前缀 + 大驼峰 OYUserCode
3. 单词大写加'_' USER_CODE
枚举:下面是个我写的启动页广告点击事件的枚举,可以参考下
typedef NS_ENUM(NSInteger, OYLaunchImageAdViewActionType) {
OYLaunchImageAdViewActionTypeAd, //点击广告
OYLaunchImageAdViewActionTypeSkip, //点击跳过广告
OYLaunchImageAdViewActionTypeTimerOver, //广告定时器结束
};
2.6文件夹命名
创建文件夹最好创建实体文件夹,找到工程目录,创建相应文件夹并拖入工程。
文件夹命名使用相应模块的英文,首字母要大写。
分享下Xcode8的两个注释快捷键
- command + / 所选行会被注释掉
- command + option + / 在方法名或变量名的所在行或上一行使用,会自动填充注释段,可输入方法参数的意思或者作用。
3.编码规范
- 删除多余的空行
1.1 所有的方法之间空一行
1.2 所有的代码块之间空一行 - 删除多余的注释
2.1 删除不用的代码
2.2 删除没有意义的注释 - 删除多余的方法
3.1 如果有方法一直不会用到,请删除(除工具类)
3.2 没有执行任何业务逻辑的方法,请删除或给予注释 - 删除多余的资源或文件
- 添加必要的注释
5.1 所有 .h 文件中的property 需要给出清晰注释,非必要变量请勿防止出现在 .h文件中
5.2 比较大的代码块需要给出注释
5.3 所有自定义的方法需要给出注释
5.4 所有代码中出现的阿拉伯数字需要给出注释
5.5 程序中出现加密/解密 逻辑的操作地方,需要给出注释说明过程(无论是系统还是自定义) - 尽量少用大段打印,非必要可以注释或删除,尽量消除警告(不影响程序正常运行)
- 整体代码风格要统一
7.1 代码后的'{'不需要独占一行
7.2 运算逻辑符和变量之间空一格
7.3 多用#pragma mark - xxx讲方法分块,#pragma mark与下面的代码之前不要空行
7.4 遵循一般代码规范,多模仿苹果API
4.通用规范
1 下面所有规则对第三方类库无约束
* 所有类、方法、属性等命名,做到见名知意,采用驼峰式命名规则
* 根据资源类型或者所属业务逻辑对项目资源进行分组,使得整个项目结构清晰明了
* 整个项目保持一种代码书写风格(这个风格由无锡团队根据自己编码习惯来定),让你的代码变的优雅!
2. 命名规范
* 所有类名称以项目工程开头命名,eg:“XP”、“ZJG”、“SZ”
* 针对不同视图控制器,在末尾添加后缀,eg:
UIViewController 后缀添加“ViewController”
UIView 后缀添加“View”
UIButton 后缀添加“Button”、“Btn”
UILabel 后缀添加“Label"
3. 单页代码最好控制在800行以内,每个方法最好不要超过100行,过多建议对代码进行重构
4. 相同的逻辑方法定义避免在多个地方出现,尽量将公用的类、方法抽取出来
5. 删除未被使用的代码,不要大片注释未被使用的代码,确定代码不会使用,请及时删除
6. 对其他项目中copy过来的代码,根据具体需要更新代码风格,及时删除未被使用的代码
7. 项目中所有Group或者文件名称(图片名字等),不要使用汉字命名,尽量使用英文命名,国内特有名词可以使用拼音。
8. 项目中所有Group都需要在项目目录中存在一个真实的目录,Group中的文件与真实目录中文件一一对应。
9. 请在项目中写必要代码的注释
10. 请多使用 #pragma mark - Mark Name 对方法进行分组 eg:
* #pragma mark - View lifeCycle
* #pragma mark - View lifeTerm
* #pragma mark - Init methods
* #pragma mark - Action methods
* #pragma mark - Common methods
* #pragma mark - UIActionSheetDelegate
* #pragma mark - UIImagePickerControllerDelegate
* #pragma mark - UITableViewDelegate Methods
* #pragma mark - UITableViewDataSource Methods
* #pragma mark - UIScrollViewDelegate Methods
* #pragma mark - UITextFieldDelegate Methods
* #pragma mark - UITextViewDelegate Methods
网友评论