Objective-C编码规范:26个方面解决iOS开发问题
2016-06-26 12:27
696 查看
http://m.csdn.net/article/2015-06-01/2824818-objective-c-style-guide
【按语】由于我正在准备模拟开发饿了么这个App,到时可能有些iOS开发者参与进来。这时如果每个人的Objective-C编码风格都不一样,这样不易于保持代码一致性和难以Code Review。所以我在网上搜索到The
official raywenderlich.com Objective-C style guide这篇关于Objective-C编码风格的文章,觉得可以作为这个项目的Objective-C的编码标准,所以就翻译这篇文章。这篇编码风格指南概括了raywenderlich.com的编码规范,可能有些删减或修改。
我们制定Objective-C编码规范的原因是我们能够在我们的书,教程和初学者工具包的代码保持优雅和一致。即使我们有很多不同的作者来完成不同的书籍。
这里编码规范有可能与你看到的其他Objective-C编码规范不同,因为它主要是为了打印和Web的易读性。
这编码规范的创建是由很多来自raywenderlich.com团队成员在Nicholas Waynik的带领下共同完成的。团队成员有:Soheil Moayedi Azarpour、Ricardo
Rendon Cepeda、Tony Dahbura、Colin
Eberhardt、Matt Galloway、Greg
Heo、Matthijs Hollemans、Christopher
LaPollo、Saul Mora、Andy
Pereira、Mic Pringle、Pietro
Rea、Cesare Rocchi、Marin
Todorov、Nicholas Waynik和Ray
Wenderlich。
我们也非常感谢New York Times 和Robots & Pencils'Objective-C编码规范的作者。这两个编码规范为本指南的创建提供很好的起点。
这里有些关于编码风格Apple官方文档,如果有些东西没有提及,可以在以下文档来查找更多细节:
The
Objective-C Programming Language
Cocoa
Fundamentals Guide
Coding
Guidelines for Cocoa
iOS
App Programming Guide
应该使用US英语。
应该:
不应该:
在函数分组和protocol/delegate实现中使用#pragma mark -来分类方法,要遵循以下一般结构:
缩进使用4个空格,确保在Xcode偏好设置来设置。(raywenderlich.com使用2个空格)
方法大括号和其他大括号(if/else/switch/while 等.)总是在同一行语句打开但在新行中关闭。
应该:
不应该:
在方法之间应该有且只有一行,这样有利于在视觉上更清晰和更易于组织。在方法内的空白应该分离功能,但通常都抽离出来成为一个新方法。
优先使用auto-synthesis。但如果有必要,@synthesize和@dynamic应该在实现中每个都声明新的一行。
应该避免以冒号对齐的方式来调用方法。因为有时方法签名可能有3个以上的冒号和冒号对齐会使代码更加易读。请不要这样做,尽管冒号对齐的方法包含代码块,因为Xcode的对齐方式令它难以辨认。
应该:
不应该:
当需要注释时,注释应该用来解释这段特殊代码为什么要这样做。任何被使用的注释都必须保持最新或被删除。
一般都避免使用块注释,因为代码尽可能做到自解释,只有当断断续续或几行代码时才需要注释。例外:这不应用在生成文档的注释
Apple命名规则尽可能坚持,特别是与这些相关的memory management rules (NARC)。
长的,描述性的方法和变量命名是好的。
应该:
不应该:
三个字符前缀应该经常用在类和常量命名,但在Core Data的实体名中应被忽略。对于官方的raywenderlich.com书、初学者工具包或教程,前缀'RWT'应该被使用。
常量应该使用驼峰式命名规则,所有的单词首字母大写和加上与类名有关的前缀。
应该:
不应该:
属性也是使用驼峰式,但首单词的首字母小写。对属性使用auto-synthesis,而不是手动编写@synthesize语句,除非你有一个好的理由。
应该:
不应该:
【按语】由于我正在准备模拟开发饿了么这个App,到时可能有些iOS开发者参与进来。这时如果每个人的Objective-C编码风格都不一样,这样不易于保持代码一致性和难以Code Review。所以我在网上搜索到The
official raywenderlich.com Objective-C style guide这篇关于Objective-C编码风格的文章,觉得可以作为这个项目的Objective-C的编码标准,所以就翻译这篇文章。这篇编码风格指南概括了raywenderlich.com的编码规范,可能有些删减或修改。
介绍
我们制定Objective-C编码规范的原因是我们能够在我们的书,教程和初学者工具包的代码保持优雅和一致。即使我们有很多不同的作者来完成不同的书籍。这里编码规范有可能与你看到的其他Objective-C编码规范不同,因为它主要是为了打印和Web的易读性。
关于作者
这编码规范的创建是由很多来自raywenderlich.com团队成员在Nicholas Waynik的带领下共同完成的。团队成员有:Soheil Moayedi Azarpour、RicardoRendon Cepeda、Tony Dahbura、Colin
Eberhardt、Matt Galloway、Greg
Heo、Matthijs Hollemans、Christopher
LaPollo、Saul Mora、Andy
Pereira、Mic Pringle、Pietro
Rea、Cesare Rocchi、Marin
Todorov、Nicholas Waynik和Ray
Wenderlich。
我们也非常感谢New York Times 和Robots & Pencils'Objective-C编码规范的作者。这两个编码规范为本指南的创建提供很好的起点。
背景
这里有些关于编码风格Apple官方文档,如果有些东西没有提及,可以在以下文档来查找更多细节:The
Objective-C Programming Language
Cocoa
Fundamentals Guide
Coding
Guidelines for Cocoa
iOS
App Programming Guide
语言
应该使用US英语。应该:
UIColor *myColor = [UIColor whiteColor];
不应该:
UIColor *myColour = [UIColor whiteColor];
代码组织
在函数分组和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 {}
空格
缩进使用4个空格,确保在Xcode偏好设置来设置。(raywenderlich.com使用2个空格)方法大括号和其他大括号(if/else/switch/while 等.)总是在同一行语句打开但在新行中关闭。
应该:
if (user.isHappy) { //Do something } else { //Do something else }
不应该:
if (user.isHappy) { //Do something } else { //Do something else }
在方法之间应该有且只有一行,这样有利于在视觉上更清晰和更易于组织。在方法内的空白应该分离功能,但通常都抽离出来成为一个新方法。
优先使用auto-synthesis。但如果有必要,@synthesize和@dynamic应该在实现中每个都声明新的一行。
应该避免以冒号对齐的方式来调用方法。因为有时方法签名可能有3个以上的冒号和冒号对齐会使代码更加易读。请不要这样做,尽管冒号对齐的方法包含代码块,因为Xcode的对齐方式令它难以辨认。
应该:
// blocks are easily readable [UIView animateWithDuration:1.0 animations:^{ // something } completion:^(BOOL finished) { // something }];
不应该:
// colon-aligning makes the block indentation hard to read [UIView animateWithDuration:1.0 animations:^{ // something } completion:^(BOOL finished) { // something }];
注释
当需要注释时,注释应该用来解释这段特殊代码为什么要这样做。任何被使用的注释都必须保持最新或被删除。一般都避免使用块注释,因为代码尽可能做到自解释,只有当断断续续或几行代码时才需要注释。例外:这不应用在生成文档的注释
命名
Apple命名规则尽可能坚持,特别是与这些相关的memory management rules (NARC)。长的,描述性的方法和变量命名是好的。
应该:
UIButton *settingsButton;
不应该:
UIButton *setBut;
三个字符前缀应该经常用在类和常量命名,但在Core Data的实体名中应被忽略。对于官方的raywenderlich.com书、初学者工具包或教程,前缀'RWT'应该被使用。
常量应该使用驼峰式命名规则,所有的单词首字母大写和加上与类名有关的前缀。
应该:
static NSTimeInterval const RWTTutorialViewControllerNavigationFadeAnimationDuration = 0.3;
不应该:
static NSTimeInterval const fadetime = 1.7;
属性也是使用驼峰式,但首单词的首字母小写。对属性使用auto-synthesis,而不是手动编写@synthesize语句,除非你有一个好的理由。
应该:
@property (strong, nonatomic) NSString *descriptiveVariableName;
不应该:
id varnm;
相关文章推荐
- iOS复杂动画之抽丝剥茧(Objective-C & Swift)
- 关于MarshalByRefObject的解释
- Selective Search for Object Recognition----论文笔记
- java Object类
- Object类源码学习
- iOS id、NSObject、id<NSObject>的区别
- Objective C 代码规范
- VLC调试:增加messages.c日志函数,在无vlc_object_t下打印日志
- object基础魔术方法使用代码
- object_PDO基础封装代码
- JavaScript 特殊对象 Array-Like Objects 详解
- Region-based Convolutional Networks for Accurate Object Detection and Segmentation----R-CNN论文笔记
- 毕向东Java视频学习笔记【Day11 异常+object类】
- [随记]浅谈pdfobject.js实现网页PDF文件浏览
- 1.hql查询实体:Object,hbm
- 1.hql简单属性查询:Object,hbm
- 【转载】混编ObjectiveC++
- CCLuaObjcBridge - Lua 与 Objective-C 互操作的简单解决方案
- 1.LazyForSingleEnd Object,hbm
- Object 类