|
【 题注】由于公司正在准备招新的iOS开发工程师，到时有些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;
类命名前缀+描述+类型
注:前缀可以是你的姓名/昵称等主要用于团队开发的时候避免文件名重复 以下是我个人命名方式 例:
XJX --- 姓名/昵称
Message --- 描述性本类的功能
Cell/Model --- 类型/模型
方法命名方法使用小驼峰法命名
一个规范的方法读起来应该像一句完整的话，读过之后便知函数的作用。执行性的方法应该以动词开头，小写字母开头。返回性的方法应该以返回的内容开头，但之前不要加get。 示例：
-(void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;
-(instancetype)arrayWithArray:(NSArray *)array;
常量命名通常与项目设置的类文件前缀相同，跟随其后的命名应采用驼峰命名法则，命名应准确表述常量表示的意义。 示例：
#define kRunAnnotationStartPointTitle @“起点"
typedefNS_ENUM(NSInteger, UITableViewStyle) {
UITableViewStylePlain, // regular table view
UITableViewStyleGrouped // preferences style table view
};
NSString*constUIApplicationLaunchOptionsRemoteNotificationKey;
NSString*constUIApplicationLaunchOptionsLocalNotificationKey;
图片命名原则：
1）采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等) 2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背 景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务 功能模块划分，比如用户中心，消息中心等 备注：建议背景图采用以bg作前缀，按钮背景采用btn作前缀（不作强制要求，项目实际 负责人根据团队特点确定即可） 公共模块命名示例：
导航条背影图片：bg_nav_bar@2x.png
导航返回按钮：bg_nav_back_normal@2x.png，bg_nav_back_selected@2x.png
标签item背景：bg_tabbar_record_normal@2x.png，bg_tabbar_record_selected@2x.png
私有模块命名示例： 以土冒APP的首页图片资源为例说明，
首页搜索背景图：bg_home_search@2x.png
首页消息默认背景图：bg_home_info_normal@2x.png
首页消息高亮背景图：bg_home_info_highlight@2x.png
函数命名
如果有参数，函数名应该作为第一个参数的提示信息，若有多个参数，在参数前也应该有提示信息（一般不必加and） 一些经典的操作应该使用约定的动词，如initWith,insert,remove,replace,add等等。 代码注释提及命名,不得不马上提醒代码的注释问题!很多同事的注释过于粗糙,有些甚至都没有注释习惯,导致代码可读性差,版本迭代或是需求变更的时候不能及时定位到具体代码 以下已model类为例:
/** 名字 */
@property(nonatomic,strong)NSString* name;
/** 年龄 */
@property(nonatomic,strong)NSString* age;
/** 性别 */
@property(nonatomic)BOOL sex;
注释统一采用文档注释方式:/** */
这样注释的好处是: 当你调用这个属性时会具有相关备注提示 例:
题外话 - Xcode插件 - VVDocumenter这是一个文档注释插件,可以帮助开发者快速的注释,提高工作效率,这也是本人比较常用的一款插件,具体效果请前往github查看 附上github链接:https://github.com/onevcat/VVDocumenter-Xcode 代码组织 在函数分组和protocol/delegate实现中使用#pragma mark -来分类方法：
#pragma mark - Lifecycle
-(id)init{}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}
#pragma mark - Custom Accessors
- (void)setUpTableView{}
#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 的一部分代码规范 #本人QQ:1103868202... 新建QQ群:398369031
#欢迎来讨论交流技术。 #PS:(现就职于杭州梦想小镇. 蓝麦电商 )
|
