【按语】由于我公司正在准备开发新的App，到时可能有些iOS开发者参与进来。这时如果每个人的Objective-C编码风格都不一样，这不易于保持代码一致性和难以Code Review。
介绍
这里有些关于编码风格Apple官方文档，如果有些东西没有提及，可以在以下文档来查找更多细节：
- The Objective-C Programming Language
- Cocoa Fundamentals Guide
- Coding Guidelines for Cocoa
- iOS App Programming Guide
语言
请使用US英语!!! 不要使用拼音!!!
命名
Apple命名规则尽可能坚持，特别是与这些相关的memory management rules (NARC)。
本文推荐驼峰法，也是Objective-C社区的标准。
驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一个单词之外，其他单词首字母大写。大驼峰法相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。
属性命名
描述性的单词+变量类型 是最好的,一目了然 例如:
UILabel *nameLabel;
类命名
前缀+描述+类型
注:前缀可以是你的姓名/昵称等主要用于团队开发的时候避免文件名重复
以下是我个人命名方式 例:
- DNS(大楠神) --- 请无视我自恋
- Message 描述性本类的功能
- Cell 类型
方法命名
- 方法使用小驼峰法命名
- 一个规范的方法读起来应该像一句完整的话，读过之后便知函数的作用。
- 执行性的方法应该以动词开头，小写字母开头
- 返回性的方法应该以返回的内容开头，但之前不要加get。
示例：
- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;
- (instancetype)arrayWithArray:(NSArray *)array;
常量命名
常量(预定义，枚举，局部常量等)使用小写k开头的驼峰法，比如kInvalidHandle ,kWritePerm
示例：
#define kRunAnnotationStartPointTitle @“起点"
typedef NS_ENUM (NSInteger,RunGoalTypeE){
kRunGoalTypeNone = 0, //无目标
kRunGoalTypeTime = 1, //以时间为目标
kRunGoalTypeDistance = 2, //以距离为目标
kRunGoalTypeCalori = 3, //以消耗卡路里为目标
};
NSString *const kGroupInfoName =@"name";
图片命名
先看下新浪微博app图片资源命名方式，下面是部分截图：
这个图片资源命名方式，以功能为组织形式，是一个很好的习惯，有利于查看资源文件。
原则：
1.采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)
2.采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务功能模块划分，比如用户中心，消息中心等
备注：建议背景图采用以bg作前缀，按钮背景采用btn作前缀（不作强制要求，项目实际负责人根据团队特点确定即可）
公共模块命名示例：
导航条背影图片：[email protected]
导航返回按钮：[email protected]，[email protected]
标签item背景：[email protected]，[email protected]
私有模块命名示例：
以Joggers APP的用户中心图片资源为例说明，
uc——user center
用户中心头像默认图：[email protected]
用户中心顶部默认背景图：[email protected]
用户中心底部背景图：[email protected]
这部分工作较为繁杂，并且在程序员心中会认为是技术含量较低的一个工作，但图片命名的严谨性同样会反映出我们对细节的追求，细节决定成败。
如果有参数，函数名应该作为第一个参数的提示信息，若有多个参数，在参数前也应该有
提示信息（一般不必加and）
一些经典的操作应该使用约定的动词，如initWith,insert,remove,replace,add等等。
代码注释
提及命名,不得不马上提醒代码的注释问题!很多同事的注释过于粗糙,有些甚至都没有注释习惯,导致代码可读性差,版本迭代或是需求变更的时候不能及时定位到具体代码
- 以下已model类为例:
/** 时间 */
@property (nonatomic, strong) NSString *time;
/** 文字 */
@property (nonatomic, strong) NSString *text;
/** cell类型 */
@property (nonatomic, assign) DNSMessageType type;
/** cell高度 */
@property (nonatomic, assign) CGFloat cellHeight;
/** 时间是否显示 */
@property (nonatomic, assign, getter=isHideTime) BOOL hideTime;
注释统一采用文档注释方式: /** */
- 这样注释的好处是:
当你调用这个属性时会具有相关备注提示 例:
题外话 - Xcode插件 - VVDocumenter
这是一个文档注释插件,可以帮助开发者快速的注释,提高工作效率,这也是本人比较常用的一款插件,具体效果请前往github查看
附上github链接:https://github.com/onevcat/VVDocumenter-Xcode
代码组织
在函数分组和protocol/delegate实现中使用#pragma mark -来分类方法：
#pragma mark - Lifecycle
- (instancetype)init {}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}
#pragma mark - Custom Accessors
- (void)setCustomProperty:(id)value {}
- (id)customProperty {}
#pragma mark - IBActions
- (IBAction)submitData:(id)sender {}
#pragma mark - Public
- (void)publicMethod {}
#pragma mark - Private
- (void)privateMethod {}
#pragma mark - Protocol conformance
#pragma mark - UITextFieldDelegate
#pragma mark - UITableViewDataSource
#pragma mark - UITableViewDelegate
#pragma mark - NSCopying
- (id)copyWithZone:(NSZone *)zone {}
#pragma mark - NSObject
- (NSString *)description {}
有人可能不明白这种注释的好处,上两张对比图大家可以直观的感觉一下
- 未注释
- 注释
- 作用
- 告诉Xcode编译器,要在编译器窗格顶部的方法和函数弹出菜单中将代码分隔开.
- 一些类(尤其是一些控制器类)可能代码量非常大,方法和函数弹出菜单可以便于代码导航.此时加入#pragma 指令对代码进行逻辑组织就显得非常有效果
黄金路径
当使用条件语句编码时，左手边的代码应该是"golden" 或 "happy"路径。也就是不要嵌套if语句，多个返回语句也是OK。
- 应该:
- (void)someMethod {
if (![someOther boolValue]) {
return;
}
//Do something important
}
- 不应该
- (void)someMethod {
if ([someOther boolValue]) {
//Do something important
}
}
以上是Objective - C 的一部分代码规范, 今天先写到这,日后再慢慢补充