一、命名规范
命名规则对于维护代码来说是非常重要的,。Objective-C方法名往往很长，不过这也有好处，让很多注释变得毫无意义。
1、驼峰法
Objective-C社区的标准，驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一个单词之外，其他单词首字母大写，一般用于变量命名。大驼峰法相比小驼峰法，大驼 峰法把第一个单词的首字母也大写了，一般用于对象命名。
2、基本原则
1） 清晰（可读性高）
又清晰又简洁是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是 以什么方式做了什么事情，不要让人有疑问
2） 一致性
做某个事情代码通常都叫这个名字，比如tag、setStringValue，那么你也这么叫。你在不确定怎么起名字的时候，可以参考一些常用的名字：Method Arguments
3）禁止使用中文或拼音（英文不好？ 有道一下啦）
3. 类命名
类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类（或者类的对象）是做什么的。在应用级别的代码里，尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码，前缀就是可接受并推荐的做法了(型如 MWPhotoBrowser )。
4. 类别命名（Category）
类名+标识+扩展（UIImageView +HP+Web）
类别的方法应该都使用一个前缀(型如hp_myCategoryMethodOnAString ),以防止Objective-C代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address-space)，方法命名规则就没必要恪守了。
5. 方法命名
方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话，读过之后便知函数
的作用。执行性的方法应该以动词开头，小写字母开头，返回性的方法应该以返回的内容
开头，但之前不要加get。
6. 变量命名
1）变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。必须起有意义的名字，使其他组员可以很容易读懂变量所代表的意义，变量命名可以采用同义的英文命名，可使用几个英文单词。别一心想着少打几个字母，让你的代码可以迅速被理解更加重要。
2）对于一些特殊类型的变量，命名时要带上类型，如NSArray 的变量命名为xxxArray 或xxxList，其他的如xxxDictionary，xxxSize等。这样就可以从名称上知道是什么类型的变量。千万不能将NSArray的变量命名为xxxDictionary。
3）对于UI控件变量，命名时后缀要以特定的控件名。
如：@property (weak, nonatomic) IBOutlet UILabel *versionLabel;
4）控制器的后缀必须加ViewController， 名字过长的情况下也必须加上Controller作为后缀；
5） 普通View后缀必须加View，UITableViewCell和UICollectionViewCell后缀必须加Cell；
6）成员变量命名，尽量采用@property方式来申明变量，如果不用@property方式申明变量，则必须采用前缀下划线来申明变量
7. 常量命名
1）对于常量的命名最好在前面加上字母k作为标记. 如:
static const NSTimeInterval kAnimationDuration = 0.3;
2）定义作为NSDictionary或者Notification等的Key值字符串时加上const关键字, 以防止被修改，通知的name一定要以Notification作为后缀。如:
NSString *const UIApplicationDidEnterBackgroundNotification
3） 避免在程序中直接出现常数，使用超过一次的应以宏定义的形式来替代。
8. 枚举命名
枚举类型命名要加相关类名前缀并且枚举值命名要加枚举类型前缀.
typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {
UIViewAnimationTransitionNone,
UIViewAnimationTransitionFlipFromLeft,
UIViewAnimationTransitionFlipFromRight,
UIViewAnimationTransitionCurlUp,
UIViewAnimationTransitionCurlDown,
};
9. 图片资源文件命名
原则：
1）采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)
2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背
景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务
功能模块划分，比如用户中心，消息中心等
注：Assets.xcassets中文件夹必须分模块，命名必须小写，图片必须命名好之后再放入Assets.xcassets中。通常来说，Assets中至少包含common，tabbar，navigation这三个模块。
公共模块命名示例：
背景图采用以bg作后缀缀，按钮背景采用btn作后缀;
导航条背影图片：[email protected]
导航返回按钮：[email protected]
标签item背景：[email protected]，[email protected]
通用cell占位图：[email protected]
私有模块命名示例：
以用户中心图片资源为例说明：
用户中心头像默认图：[email protected]
用户中心顶部默认背景图：[email protected]
9. 目录命名
用英文命名时，首字母大写，可以用中文命名，但是禁止使用拼音命名。
二、编码排版格式
1、代码的缩进应使用空格（SPACE），不能使用制表符（TAB），并且缩进以2个 字符为单位。快捷方式：Command + A —— > Control + I
2、 中括弧的每一个括弧在源程序中要单独占一行。
3、 空格的使用
a) 关键字与其后的表达式之间要有空格
b) 单目操作符不应与它们的操作数分开（如’!’和’^’等）。
c) 除’ , ’外，其它双目操作符应与它们的操作数用空格隔开。
d) .h中协议<>前面有一个空格。
e) .h中成员声明时，类型与变量之间有至少1个空格。*号靠近变量，不靠近类型。
f) @property后留1个空格，（）里面，逗号紧跟前一变量，与后一变量之间留1 个空格。（）外面，先留1个空格，再声明属性。
g) 方法的+，-后面与（）之间留1个空格。
h) 返回类型与*之间留1个空格，方法参数中返回类型与*之间留1个空格。
i) 在多参数方法中，每个参数后面都有1个空格。
4、 每行只能有一个语句
5、关于空行
a) .h中的空行
1、文件说明与头文件包含(#import)之间空1行
2、头文件包含(#import)之间，如果需要分类区别，各类别之间空1行。
3、头文件包含(#import)与@class之间空2行。
4、@interface与@class之间空1行。
5、头文件{}里面，空1行开始声明对象成员，如果需要分类区别，各类别之间空1行。
6、头文件{}外，空1行书写属性，如果需要分类区别，各类别之间空1行。
7、属性下面空1行开始写方法，如果需要分类区别，各类别之间空1行。
8、方法完成后，空1行@end。
9、如果需要声明protocol，空2行接着写。通常protocol写在@end后面，但是声明在@interface之前。
b) .m中的空行
1、文件说明与头文件包含(#import)之间空1行
2、头文件包含(#import)之间，如果需要分类区别，各类别之间空1行。
3、@implementation和@synthesize之间空1行, 如果需要分类区别，各类别之间空1行。
4、方法与方法之间空1行。
c) 方法里面的空行
1、变量声明后需要空1行，如果需要分类区别，各类别之间空1行。
2、条件、循环，选择语句，整个语句结束，需要空1行。
3、各功能快之间空1行。
4、最后一个括弧之前不空行。
5、注释与代码之间不空行。
6、#pragma mark 与方法之间空1行。
d) 每行代码最多不得操作100个字。设置如下：Xcode => Preferences => TextEditing => Page Guide at column /输入 100即可。
6、注释
1、变量名、方法名等不足以说明实际意义的时候，必须要写注释；
2、类名不足以提现类的作用的时候，必须在类声明的上面添加注释，说明类的基本作用。
3、可能涉及到注释的地方主要包括：
类注释、方法注释、成员变量注释、枚举注释、宏定义注释、宏定义方法注释、逻辑注释、Protocol注释
4、推荐使用VVDocumenter
5、文件夹：所有新建的目录，在工程下必须存在实体目录；
6、单页面代码不得超过800行，单个方法不得超过50行。
3 、规定
1、 dealloc方法 规定：一个类的dealloc方法如果有必要存在，必须是.m中的最后一个方法，方便查找；
2、非特殊需要，不允许将UI控件的property直接创建到.h文件中；
3、当需要一定条件才执行某项操作时，最左边的应该是最重要的代码，不要将最重要的代码内嵌到if中。
如良好的风格是：
- (void) someMethod {
if(![someOther boolValue]) {
return;}
//最重要的代码写在这里；
}
反面教材：
- (void) someMethod {
if([someOther boolValue]) {
//重要代码；}
}
4 、建议
1、尽量不使用for循环，可用forin或者enumerateObjectsUsingBlock进行遍历；
2、尽可能保证 .h文件的简洁性，可以不公开的API就不要公开了，写在实现文件中即可；
3、建议使用“#pragma mark”，方便阅读代码。有些由于数据等方面问题需要以后做处理的使用#pragma warnning”进行提醒;
4、if-else超过四层的时候，就要考虑重构，多层的if-else结构很难维护；
5、UIView的子类初始化的时候，不要进行任何的布局操作。布局操作应该在layoutSubviews里面做；需要重新布局的时候调用setNeedsLayout，而不要直接调用layoutSubviews。（一般代码创建的时候这样做）；
6、推荐方法的第一个花括号直接跟在方法体后，而不是另起一行，这样可以减少代码行；
7、方法体中的第一行留空，最后一行不留空，这样一个方法就会比较清晰，但是如果该花括号里面又是一个if，for之类的带花括号的语句块，那么上述的第一行可以不留空。
同样，如果花括号内第一行是注释的话，第一行也可以不留空。注释也起到了分隔代码的作用，看起来比较清晰。
再者，如果花括号内只有一行代码，第一行可以不留空。du -k repos