iOS App 开发的那些事儿 1:如何建立合适的规范

《iOS App 开发的那些事儿》系列文章从更宏观的角度出发,不仅仅局限于具体某个功能、界面的实现,而是结合网易云信 iOS 端研发负责人多年的经验,从如何优化现有代码的角度出发,深度分析如何创造出 iOS App 开发中比较合适的规范和框架。

将代码规范合理分级

大家都理解软件开发需要合适的规范:代码规范,程序规范,流程规范等等,以此来减少意外的出现:最少惊讶原则。但在实际执行中却会碰到各种情况,其中最大的问题是:怎么鉴别哪些规范是需要强制执行,哪些规范是推荐执行。
规范的强制执行带来的是代码的可读性提升和二义性减少,而坏处也是显而易见的:对于大部分有想法的程序员而言这种规定太死板,容易引起抵触心理,产生不安定因素。这种情况常见于各种标准的外包公司。
而如果大部分的规范设定为推荐执行,在没有良好的引导下,规范容易被忽视。 网上有很多关于ObjC的代码规范,比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级:强制要求,强烈推荐(但不强制),良好,可接受和不可接受。
以下仅举部分例子加以说明。

符合苹果规范的命名方式

  • 类名开头大写,方法和变量名以驼峰法命名。强烈要求,这没有什么好说的,苹果系统类库和绝大多数的第三方开源库都是如此。但在部分苹果的 sample 中也看到过用m做前缀表示类成员变量的写法,这些都是属于遗产代码的问题,仍旧是可接受范围,但是自己代码内部使用类似匈牙利的命名法就是不可接受。
  • 类名使用至少三个字符做前缀,内部方法使用两个下划线做前缀。强烈推荐。上面的做法可以最大程度避免和系统类库发生重名的情况:因为苹果宣称保留所有两位字符前缀的使用权,同时其内部方法命名以一个下划线做前缀。
  • 无论使用 K&R Style 还是 Allman Style 都是可接受的范围,但是强烈推荐在一个文件内保持一种形式。
  • 在保证代码可读性的基础上保持代码的简短和统一性:小类,小方法,统一的函数返回。小类,小方法可以保证他人阅读时更方便地关注类逻辑,而不是具体细节,而统一的函数返回可以减少意外错误和降低错误排查的难度。而保证代码的简短和不罗嗦也是很重要一点,经常会看到如下代码: if (count > 1) { return YES; } { return NO; },真心无法直视。

良好的代码/工程结构

  • 为整个工程创建 workspace。
  • 按照权责分门别类存放资源文件:每种类型的资源存放于独立的目录下:图片,声音,配置文件等等。而图片又可以按照类型分别存放在不同的子目录下:全局类型,背景图,logo,登录等等。
  • 合理的代码结构。

Core:工程内一些通用的机制实现类:统一的任务管理,模块管理,服务管理。
General:公用类和方法,包括工程内ViewController,UITableViewCell基类(Base),公用Category(Category):公用UI组件(CustomUI),公用辅助方法(Helper)和宏定义(Marco)。
Model:公用数据模型
Sections:不同程序单元。如登录,设置等等。其下又可以按照功能分成不同的子目录:当前单元使用的自定义UI组件,管理类,数据模型和ViewController等等。
Vendors:第三方库。

《iOS App开发的那些事儿》第二篇文章将会向大家介绍什么是合适的框架,如何搭建合适的框架,欢迎大家积极发表自己的看法,与我们共同讨论。


随着即时通讯以及音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,如果你有好的技术或者分享,欢迎关注网易云信官方博客和 GitHub:

关注更多技术干货内容: 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网

你可能感兴趣的:(objective-c,viewcontroller,model,category)