iOS架构师之路:制定代码规范

自我引进的代码规范

《The Objective-C Style Guide used by The New York
Times》
(简称:New
York,该标准也有中文版),《New
York》是自我相比喜欢的编码规范风格,它是《Zen》的编码思想一个很好的执行。

1.iOS切图文件的命名规范

那部分正式或者是很有经验的规划提供,也有可能是大家开发人士提供,领会总是没有坏处的。

咱俩的命名规则的基本思想是把文件名分成三片段,第一部分是图表的逻辑归属分类,第二有些是图形的显现内容,第三有的是图片的情节的序列,有些图片还会有第四局地,表示图片表现的处境。首先有多少个规则是:

  • 用英文命名,不用拼音
  • 每一局部用下划线分隔
  • 图片名中两倍图在名字最后要加@2x,三倍图在名字最终要加@3x

万能公式

image_naming_guideline.png

3.属性伊始化放哪最好?提议在Getter中先导化

自我看出不少APP,甚至自己公司的门类,很多费用工程师,开首化属性的地点比较自由,有独立添加一个起首化方法类似setupView的,有在init伊始化的,种种情况都有,我骨子里挺崩溃的,首先初叶化格局分裂,其次也如此做更加有可能破坏了每个方法效果的单一性(每个方法只做一件事)。我比较习惯一个目的的”私有”属性写在extension里面,然后那么些属性的发轫化全体放在getter里面做,在init和dealloc之外,是不会现出任何类似_property这样的写法的。就是如此:

@interface CustomObject()

@property (nonatomic, strong) UILabel *label;

@end

@implementation

#pragma mark - getters and setters

- (UILabel *)label {
    if (_label == nil) {
        _label = [[UILabel alloc] init];
        _label.text = @"1234";
        _label.font = [UIFont systemFontOfSize:12];
        ... ...
    }
    return _label;
}
@end
#pragma mark - life cycle

- (void)viewDidLoad {
    [super viewDidLoad];
    [self.view addSubview:self.label];
}

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    self.label.frame = CGRectMake(1, 2, 3, 4);
}

唐巧说她喜欢的做法是用_property那种,然后关于_property的开始化通过[self setupProperty]那种做法去做。从刚刚方面的代码来看,就是要在viewDidLoad里面多调用一个setup方法而已,然后自己推荐的点子就是并非多调一个setup方法,直接走getter。

哦,怎么说呢,其实二种做法都能做到要求。不过从另一个角度看,苹果之所以选取让[self getProperty]self.property可以相互通用,那种做法已经很明朗地发挥了苹果的倾向:希望每个property都是由此getter方法来博取。

早在二零零三年,Allen Holub就发了篇小说《Why getter and setter methods are
evil
》,自此之后,业界就对此发生了各类争议,纵然是从Java伊始说的,可是发展到末端各样语言也涉足了进去。然后尽管现在有关那么些题材商讨得少了,但是如故属于没有结论的情形。setter的意况比较复杂,也不是自我这一节的显要,我这边仍然根本说getter。大家从objc的布署来看,苹果的设计者尤其倾向于getter
is not evil。
以为getter is
evil的原故有这些之多,或大或小,随着冲突的进展,大家渐渐就聚焦到这般的一个原因:Getter和Setter提供了一个能让外部修改对象内部数据的章程,那是evil的,正常情形下,一个对象自己个人的变量应该是唯有和谐关切。

下一场大家再次来到iOS领域来,objc也同等面临了这么的标题,甚至更为严重:objc并从未像Java那么严苛的私家概念。但在实质上工作中,大家不太会去操作头文件之中没有的变量,那是从规范上就被明令禁止的。

认为getter is not
evil的原由也得以聚焦到一个:中度的封装性。getter事实上是工厂方法,有了getter之后,业务逻辑可以越发专注于调用,而不用担心当前变量是不是可用。我们得以想转手,若是一个ViewController有20个subview要加盟view中,那20个subview的初叶化代码是自然逃不掉的,放在何地比较好?放在何地都比位居addsubview的地点好,我个人觉得最好的地方依然放在getter里面,结合单例情势之后,代码会那一个利落,生产的地点和选择的地点获得了很好的区分。
之所以放到iOS来说,我要么觉得采用getter会相比较好,因为evil的地点在iOS那边基本都防止了,not
evil的地点都能享用到,如故不错的。

2.类的布局

程序布局的目标是显得出程序能够的逻辑结构,进步程序的准确性、延续性、可读性、可维护性。更重视的是,统一的次第布局和编程风格,有助于增强总体项目标付出质量,提升支付功用,下跌开发开支。同时,对于一般程序员来说,养成杰出的编程习惯有助于增高自己的编程水平,升高编程作用。由此,统一的、卓越的次序布局和编程风格不仅仅是私房主观美学上的或者格局上的难题,而且会涉嫌到产品质量,涉及到个人编程能力的拉长,必须引起大家尊崇。

论代码规范的重点

  • 1.架构师要为整个项目技术趋势的腾飞负责,所以制定一个一箭双雕的代码规范,让开发工程师遵循,有利于项目朝着您预见的大方向前行。比如当您向利用AOP技术落成日志成效时,就必要确定部分方式命名。
  • 2.同一的代码规范,有利于代码reveiw工作。假若每个工程师写的代码风格不平等,review代码的同事,阅读起来肯定不顺畅。
  • 3.渴求工程师依据代码规范写出同样的代码,就不怕他跳槽。那行本来就浮躁,流动性大,借使工程师写的代码风格只有她协调能看懂,那东西他跳槽,新人是很难继续有限支撑那部分代码的,以珠弹雀。

结尾

夜深人静,该睡了。欢迎收藏的
自我的博客

2.2类协会布局

使用#pragma mark –来分类方法

#pragma mark – Life Cycle

#pragma mark - Events

#pragma mark – Private Methods

#pragma mark - UITextFieldDelegate

#pragma mark - UITableViewDataSource

#pragma mark - UITableViewDelegate

#pragma mark - Custom Delegates

#pragma mark – Getters and Setters

4.Getters and Setters放在最底部

本身前面写代码一直把Getters and Setters
放在implementation的最前面,明日看大神casatwy说最好放在最终边,我觉得更有道理。控制器可能会有突出多的view属性和其他品质,假使拥有的getters
and
setters放在眼前,就会导致在implementation代码顶部有大气的初步化代码,那就造成主要的逻辑代码挪到后边去了,其外人阅读代码是不太方便的。

2.3布局中的空格

各类方法或者作用块之间为了社团清晰,应当有且唯有一行空格。

@interface SomeClass:NSObject

@property (noatomic, strong) UIView *aView

- (void)someMethod;

@end

@implementation SomeClass

- (void)setAView:(NSInteger )aview {

}

- (void)someMethod {

}
@end

前言

先吹个牛,我打心眼自认为自己是爱好对团队项目标代码品质负责的人,对于思考怎么着写出高质量可读性的代码我是乐此不彼。以前自己写过两篇有关代码命名规范和代码编写规范的篇章,《iOS架构师之路:iOS开发(OC)中的命名规范》《iOS架构师之路:IOS项目中的编码规范》,您如果心绪很好,就去看看啊,倘若低于很好,那不提议你看,怕你心里骂娘,因为明天看,感觉温馨写的不太认真,有那些下边可以写的更细致,恩,我主宰给自己帖贴金,不能够那样说自己:其实这八个月小哥我在代码规范地点的文化又见涨不少,所以看此前定制的业内不爽,作为架构师保持谦虚,通过不断学习,不断自我更正,对代码有几许洁癖是该有的威仪(潜台词其实我想说自己有)。制定项目标代码规范对架构师的最主要,似乎要你生个娃一如既往,权利重先生大,万毕生出来缺胳膊少腿,娶不到女儿,你之后就是伺候她一生,给她当牛做马,他也不自然会念你的好。

培育代码洁癖

给大家推荐一本有关代码规范的力作,第一本:《禅与 Objective-C
编程艺术(Zen and the Art of the Objective-C Craftsmanship
中文翻译)》
(简称:Zen),这本书开源社区的大牛,无偿贡献出来的,该书给大家介绍许多写代码的没错姿势,并表达为何接纳那一个姿势体验更好。看完那本书应该明了怎么写出优雅、高可读性并且可相信的代码了。

至于《Zen》、《New York》代码规范的补给

2.1.文书布局

【规则2-1-1】遵守统一的布局顺序来书写头文件。

说明:以下内容如若某些节不必要,可以忽略。可是其余节要保持该次序。**
**
头文件布局:

文件头
#import (依次为标准库头文件、非标准库头文件)
全局宏
常量定义
全局数据类型
类定义

正例:

/***************************************************************************
 *                                文件引用
 ***************************************************************************/ 
/***************************************************************************
 *                                 类引用
 ***************************************************************************/

/***************************************************************************
 *                                 宏定义
 ***************************************************************************/
/***************************************************************************
 *                                 常量
 ***************************************************************************/ 
/***************************************************************************
 *                                类型定义
 ***************************************************************************/ 
/ ***************************************************************************
 *                                 类定义
 ***************************************************************************/

【规则2-1-2】遵从统一的布局顺序来书写完成公文。
说明:以下内容借使某些节不须要,可以忽略。不过其余节要保持该次序。
心想事成文件布局:

文件头(参见“注释”一节)
#import (依次为标准库头文件、非标准库头文件)
文件内部使用的宏
常量定义
文件内部使用的数据类型
全局变量
本地变量(即静态全局变量)
类的实现

正例:

/***************************************************************************
 *                                文件引用
 ***************************************************************************/ 
/***************************************************************************
 *                                 宏定义
 ***************************************************************************/
/***************************************************************************
 *                                 常量
 ***************************************************************************/ 
/***************************************************************************
 *                                类型定义
 ***************************************************************************/
/***************************************************************************
 *                                全局变量
 ***************************************************************************/
/***************************************************************************
 *                                 原型
 ***************************************************************************/
/ ***************************************************************************
 *                                类特性
 ***************************************************************************/
/ ***************************************************************************
 *                                类的实现
 ***************************************************************************/
2.4关于布局中的Private Methods块,正常状态下ViewController里面不应有写

不是delegate方法的,不是event response方法的,不是life
cycle方法的,就是private
method了。对的,正常情况下ViewController里面一般是不会存在private
methods的,那么些private
methods一般是用来日期换算、图片裁剪啥的那种小效能。那种小成效如故把它写成一个category,要么把他做成一个模块,哪怕那一个模块只有一个函数也行。
ViewController基本上是多数事情的载体,本身代码已经极度复杂,所以跟工作关系不大的事物能不放在ViewController里面就无须放。别的一些,那一个private
method的效应这时候只是你用收获,然而将来或者其余地方也会用到,一早先就独自出来,有利于未来的代码复用。