若是无代码规范。遵循大驼峰命名法。

前言

有关代码规范之话题就较普遍,没有断的对准和错,只有相对的好与生。

每个人犹生温馨之编码习惯,但是考虑到组织开支、项目后期的维护性上面,我以为还是怪有必不可少肯定一个代码规范的,不然项目进一步到深越来越难保障

命名规范


正文

胡团队开发连接要扯到代码规范、Code Review
上面也,因为每个开发者经验不同,经历的环境差,所养成的编码习惯自然也无一样

兹差不多项目都由多口搭档开发的,而且趁机人口的流淌,一个品类代码可能由几单开发者的手,这个时候,如果没有代码规范,这个类型代码维护性、阅读性这些面即会于担忧了

对此代码并没啊对与错的分,只要完成了路之职能,你是用什么艺术就的并无是怪关键。毕竟软件是给用户使用的,用户并无会见关切而的软件底层实现逻辑,只要会帮忙解决用户遇到的题材就吓了。但是代码却产生鲁棒性、松耦合/紧耦合这些区别,所以代码分好代码、坏代码
= =

吓了 不扯这些虚的了,讲一下有关iOS 项目工被的局部规范问题吧

文本命名

准:采取驼峰命名规则,即首假名必须大写,如果为词组,则每个单词的首字母必须大写,类名只能以名词或名词词组。

  • 负有类似名以MG(米果的缩写)开头;
  • 因功能模块,类添加功能模块前缀,如个人核心模块,类加MGUC前缀;
  • 继承自UIViewUITableViewCellUIButton等以ViewCellButton结尾;
  • 继承自ViewController的类以Controller结尾;
  • 继承自TableViewController的类以TableController结尾;
  • protocol定义时,前缀以MG开头,后缀以Delegate结尾;
  • Category命名,类名+标识+扩展,如UIImageView +HP+Web,命名为UIImageView+HPWeb;
  • 数据模型以Model结尾;

工程被的文书层次

  1. 第一全部一旦为此实际目录,不然表面上层级很引人注目,其实还是乱的相同团
  2. 于项目文件夹用业务模块来分,因为是团队模块出,这样子可以缩小问题所在;对于模块的复用迁移也是十分便宜的
  3. 客观之目录分层,尽量多夺举行分层,把公文安排在当在的地方,这样子对于管理也是比较便于的,比如将个ThirdComponents
    专门来管理第三正框架的,这样子就生明亮的足理解是工程到底用到了哟第三着框架,便于升级以及治本
  4. 将Resources
    文件夹打散,下落到每个模块文件夹着,这样子在模块的迁的时刻不见面留漏资源文件,而且于每个模块资源大小为可以决定,可以检测及到底是孰业务模块将保险大小为大了
  5. 尽可能不要创建Common、Core
    这些文件夹,因为这样子会导致多工具类在里边,没人保护,宁愿抽出来开组件都吓
变量和目标命名

规则:变量称呼以小驼峰法,
使变量名尽量可以想见该用属性具有描述性,每个属性命名都抬高项目后缀。

  • 看似成员变量名,遵守小驼峰法命名并前缀下划线_。如UIButton *_submitButton;
  • 片变量名,遵守小驼峰命名规则。如UIButton *submitButton
  • 通有关变量名,添加Notification为后缀;
  • 控件类型变量,命名需加上相应类别结尾;
  • 变量名需有特定的义,建议修饰+类型
  • const常量,以略写k开头,后面才词首字母大写,其余小写。如:const float kMaxHeigt = 100.0f;

开发中的业内

  1. 联命名规范

    取名尽量采取英文名称

    名称一定要是体现真实的功力意义

  2. Controller控制器的命名

    利用驼峰命名法,首字母大写,Controller结尾

    例如: PXYTradeViewController

  3. Util工具类的命名

    运用驼峰命名法,首字母大写,Helper结尾

    例如:PXYStringHelper

  4. View界面类的命名

    动用驼峰命名法,首字母大写,View结尾

    例如:PXYTradeView

  5. Plugin插件类的命名

    以驼峰命名法,PXYPlugin开始,6员功能号最后

    例如:PXYPlugin100001

  6. Delegate协议接口类的命名

    动驼峰命名法,首字母大写,Delegate结尾

    例如:PXYServerDelegate

  7. Service业务服务类的命名

    采取驼峰命名法,首字母大写,Service结尾

    例如:PXYTradeService

  8. 注规范

    复杂的函数需要写注释,但是那些对通用的函数就不用写注释了,反而会污染代码,注释的讲话统一用系统的快捷键来创造

  9. 代码中尽量不要闹冗余的代码,当时调试时注释的代码,之后要拿未用底注解代码删除,文件中尽量去没因此之变量和函数,多余的换行

  10. 以峰文件被证下这个类似的意向

  11. 打印日志的时 禁止使用NSLog 要动自定义之Log,避免Log 上生

  12. 代码里面禁止采取 #if 0 #elif 1 #endif 之类的 难以阅读调试

  13. 犯通告之Name,缓存的Key 要用宏或者静态变量,不要一直运用字符串

  14. 毫不来无谓的空格 换行之类的

枚举命名

规则:遵循大驼峰命名法,如:

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {
    UIViewAnimationTransitionNone,
    UIViewAnimationTransitionFlipFromLeft,
    UIViewAnimationTransitionFlipFromRight,
 UIViewAnimationTransitionCurlUp,
    UIViewAnimationTransitionCurlDown,
};

最后

实质上这种代码规范上网一搜一颇把,这里虽大概列举自己碰到的题材,需要详细的上网搜一下即便吓了。规范定下来了,接下去便执行了,一开始或会见无顶习惯,但是坚持了一段时间,就会深感还好了。

方法命名

条件:遵守小驼峰原则,首字母小写,其他单词首许母大写,每个空格分割的称呼为动词开头。

A 代理方
  • 因为发送代理的目标类名作为代理方名之始(去丢类名的前缀,并且有点写起)
B 实例方法
  • 执行性的不二法门应该坐动词开头,小写字母开头;
  • 返回性方法,若返回值为单个值,在脑部加上单词get;
  • 返回性的办法应该以回到的情节开始,但前毫无加get;
资源命名

原则:“模块+功能”命名法

  • 然采取公认无歧义的缩写,如:background对应bg ,
    viewcontroller对应vc,button对应btn,navgation对应nav
  • 模块分为集体模块、私有模块:公共模块主要概括合并的背景,导航条,标签,公共的按钮背景,公共的默认图等等;私有模块主要因app的业务功能模块划分,比如用户基本,消息中心等于。
  • 假如用户中心用户头像图片的命名可以呢:uc_imageview_user_icon

编码规范


原则:可复用, 易维护, 可扩展.

注释
  • 变量注释应详细描述变量用处(文档注释)
  • 枚举注释应详细描述枚举和各个一个元素用(文档注释)
  • 方法注释应详细描述方法作用、参数意义、返回值意义(文档注释)
  • 任何使用单行注释
资源文件
  • 资源文件全部放入Supporting Files文本夹下
  • app支持iOS8与以上,图片资源放入Assert.xcassets,可依据功能模块分类或资源分类建立自己的Folder
  • app支持iOS7以及以上,图片资源放入Resources文件夹,各个资源以功能模块或资源分类放在相应的文件夹内
设计模式

规则:项目分:http://o9zrwgllm.bkt.clouddn.com/%E6%9E%B6%E6%9E%84%E7%A4%BA%E6%84%8F%E5%9B%BE.png

  • 单个模块使用MVC,或MVVM
  • 对于可重复使用的模块,应抽离为单独工具模块,留好清晰的进口以及出口
  • 确立世界(业务)模型,解耦图形界面,数据存储和事务逻辑
  • 抽离较独立的意义,抽离对应之service
单元测试

法:使用Apple自带的XCTest框架进行单元测试

  • 于接口和可进行模块化测试的片段,应编制对应的单元测试,测试包含边界条件测试,非法条件测试,性能测试相当
老三方库管理
  • 对此引入的老三方库,统一使用cocoapods进行保管
  • 苟第三在库需要改调用效果,尽可能用Category或子类重写调用效果
本子管理
  • 应用git进行版本管理
  • 交给log,最好清晰表达相关的效用修改,若修改bug,最好长bug编号
  • 颁发的不可开交本子,打tag标示对应之本,tag名称规则吧正式版版本_日期,如5_5_20160715
注意:
  • 注意变量的强弱引用
  • 在意block等循环引用问题
  • 留神解耦UI,数据,业务逻辑
  • 专注各种疑难操作尽可能不打断主线程

相关文章