1.前言
有人说，看一个开发者的水平如何，从看他代码的命名可以大致得出结论。好的命名除了可以让项目成员快速且更好的理解代码，自己读起来也赏心悦目。为此，特地根据自己平常的一些编码规范和网上一些资料进行整理汇总，方便移动开发人员时常查看对比
2.基本原则
2.1.代码清晰
又清晰又简洁的代码当然是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是以什么方式做了什么事情，不要让人有疑问！
2.2.一致性
代码保持一致，例如：创建UI相关的方法,可以使用统一的方法命名，所见即所得，见表知其意，这样，既保证了代码的一致性，也可以方便我们后续维护和管理，也利于团队代码风格的一致，协调！
3.基本命名法
编程中比较常见的有下面三种命名方式
驼峰(Camel)命名法:又称小驼峰命名法，除首单词外，其余所有单词的第一个字母大写。
帕斯卡(pascal)命名法:又称大驼峰命名法，所有单词的第一个字母大写
下划线命名法:单词与单词间用下划线做间隔
一般建议拿来做命名的单词要比较精悍短小，这样即使两三个单词一起拼装成一个命名，也不至于显得很冗长。当然有些单词我们也可以直接写成一些约定俗成的缩写。诸如：msg(message)、init(initial)、img(image)等....
4.移动开发通用规范
4.1类命名
名词，采用大驼峰命名法，尽量避免缩写，除非该缩写是众所周知的。如HTML,URL,JSON，XML等.当然也可以根据开发中的一些命名习惯进行进行缩写，比如Activity会缩写为AC，UIViewController会缩写为VC。下面是一些举例:
4.2接口命名
和类名基本一致。也可以在接口名前面再加一个大写的I，表明这是一个接口Interface。如：可以表明一个信息是否可以分享的接口，可以命名为Shareable，也可以是IShareable。
4.3方法命名
动词或动名词，采用小驼峰命名法。
下面是一些比较常见的命名风格和含义
4.4变量命名
采用小驼峰命名法。同样比较简单，但为了更好表明含义，我建议做一下的的区分。
成员变量命名前面加m（member，表示成员变量之意），如，控件的宽高 mWidth，mHeight。
4.5 常量命名
同样较为简单，全部大写,采用下划线命名法.如：MIN_WIDTH,MAX_SIZE
4.6枚举类型命名
首字母大写，之后每个单词首字母都大写，最后加“s” 枚举变量使用枚举类型去掉“s”作为前缀，每个单词首字母大写，中间不允许加下划线 举例：typedef enum UIControlEvents
{
UIControlEventTouchDown,
UIControlEventTouchUpInside
}
UIControlEvents;
4.7图片命名
这个图片资源命名方式，以功能为组织形式，是一个很好的习惯，有利于查看资源文件。
原则
- 采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)
- 采用“模块+功能”命名法，模块分为公共模块、私有模块。
公共模块主要包括统一的背景，导航条，标签，公共的按钮背景，公共的默认图等等；
私有模块主要根据app的业务功能模块划分，比如用户中心，消息中心等。
例如 :用户中心 用户头像图片的命名可以为：uc_user_icon.png
4.8通用规范
- 删除多余的空行。所有方法与方法之间空1行 所有代码块之间空1行。
- 删除多余的注释，删除注释掉的代码，删除没有意义的注释。
- 删除多余的方法。如果方法没有使用到，请删除它。如果方法没有执行任何业务逻辑，请删除它或者给出一定注释。
- 删除未被使用的资源文件
- 添加必要的注释。在类的属性，方法，比较大的代码块等位置可以添加必要的注释。
- 整体代码风格需要统一。逻辑运算符与代码之前空一格。注意大括号的位置(“{}”)，一种是起首的大括号另起一行，另一种是起首的大括号跟在关键字的后面；一般来说这两种都能够接受，请尽可能保证在一份代码中使用一种风格。
- 代码量控制。单页代码最好控制在800行以内，每个方法最好不要超过80行，过多建议对代码进行重构
- 第三方的库统一放在library目录下
5.Android平台规范
5.1包命名
- 采用反域名命名规则，全部使用小写字母。
- 一级包名为com;
- 二级包名为xx（可以是公司或则个人的随便）;
- 三级包名应用的英文名app_name;
- 四级包名为模块名或层级名;
- 下面罗列一些常见的命名划分方式:
5.2布局资源文件(layout文件夹下)
全部小写，采用下划线命名法.
下面是一些比较常见的命名风格和含义
5.3动画资源文件(anim文件夹下)
全部小写，采用下划线命名法，加前缀区分.
下面是一些比较常见的命名风格和含义
5.4 strings和colors资源文件
小驼峰命名法,命名风格大致如下：
- string命名格式：XX界面_XX功能_str,如 activity_home_welcome_str
- color命名格式：color_16进制颜色值，如红色 color_ff0000
像string通常建议把同一个界面的所有string都放到一起，方便查找。
5.5 selecor、drawable、layer-list资源文件
小驼峰命名法。命名风格通常都是XX_selector、XX_drawable、XX_layer。
下面举两个比较常用的例子：
按钮按压效果button_selector，正常状态命名为button_normal(XX_normal)，按压状态命名为button_pressed(XX_pressed)
选择效果checkbox_selector,未选中状态命名为checkbox_unchecked(XX_unchecked),选中状态为checkbox_checked(XX_checked)
5.6 styles、dimens资源文件
- style采用大驼峰命名法，主题可以命名为XXTheme,控件的风格可以命名为XXStyle
- dimen采用小驼峰命名法，如所有Activity的titlebar的高度，activity_title_height_dimen
5.7控件ID命名
以下是一些控件的缩写，可以参考进行命名：
6.IOS平台规范
6.1分类命名
与类命名相同，此处需添加需要扩展的类名和’+’
举例:NSString+URLEncoding
6.2协议(委托)命名
与类命名相同，此外需要添加‘Delegate’后缀
举例:ReplyViewDeleagte
6.3在类的头文件中尽量少引入其他头文件
通过引用 @class className; 解决编译问题。
在xxx.m 文件引人className 文件。这样可以加快编译速度。
6.4类文件组织
IOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有效地管理类文件。
类文件组织要遵循以下两大原则：
- 基于MVC设计模式原则，至少要保证controller与数据处理，网络请求相对独立 。
- 基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，数据/网络处理应该在数据/网络处理的框架下， 而UI前端界面比如用户中心，消息中心，它们的专有的controller，view等应该在属于文件夹。
还会遇到一些公共的view，可以开辟出公共的文件夹来管理。 在实际中使用中，可以结合项目特点灵活使用，但基本的原则一定要保持，保持良好的类文件组织结构，对团队有益无害。
6.5图片资源文件管理
建议采用Images.xcassets管理，尽量少用自己创建的文件夹管理。使用Images.xcassets的优势很多，具体可以查阅读相关文献资料，这里只从工程管理上说一点，在Images.xcassets中添加图片资源，不会对project文件造成改变，而直接在文件夹里添加图片文件，每次都会对project文件造成改变，因此使用Images.xcassets管理图片资源可以减少project冲突的次数。
6.6.UI组件命名
针对不同的UI组件，在末尾添加UI组件的后缀或者缩写即可。例如:
UIView 后缀添加View
UIButton后缀添加Button或者Btn
7.参考资料
http://www.jianshu.com/p/1da38a6f3173
http://www.jianshu.com/p/bb4f5033e573
http://blog.csdn.net/ws1836300/article/details/51593473
http://www.hudongdong.com/talk/448.html