iOS项目OC代码规范 -> 纯文本规范

代码规范

目的是为了组内代码风格统一，增强代码的可读性以及方便维护。这里只作一些非技术方面的代码约束要求。这里大概是参照了AFNetworking以及FaceBook开源代码作了一些tip级别的约束。

Tip1 关于注释

注释是为了说明一个代码模块或者代码段。好比你在github上丢一块代码给你们用。那么就须要你的用户在没有你的状况下可以经过你的注释用好用对你的代码。

哪些地方该写注释

我的认为该写注释的点有SDK类好比网络层、数据仓库、工具类。而像咱们常常打交道的VC我以为写好段注释足矣，在一些比较黑魔法以及比较复杂的业务逻辑写好该写上的注释便可！

怎么写

这里拿了AF的框架来作模板：

文件注释结构以下：

1. 概述 @abstract （可能等价于）

2. 详述 @discussion

3. 注意 @warning

属性注释以下：

大概描述下干啥用，以及是否有默认值，使用注意事项好比值的范围之类的。

接口注释以下：

主要仍是参数说明，返回值说明，使用注意事项以及特殊的一些声明。

对于大部分的ViewController.m文件，我的认为只要写好段注释，比如ViewLifecycle、DataSource/Delegate，Actions，IB Methods。以及在关键地方，好比业务逻辑比较复杂或者容易引发Crash的地方须要引发注意的地方补上注释。

Tip2 关于常量

用const代替define
主要缘由是会define编译器不会帮忙作一层检查。可能在运行时遇到一些Crash！
const使用在.m中对将要使用的一些常量包括字符串，整型，浮点数甚至是结构体进行声明初始化，好比：

这里补充一点是宏定义仍是有使用场景的，好比说断言，或者代码段好比判断iOS版本，好比判断设备类型这种，用宏的主要缘由是偷懒，可是须要放在一个文件内作维护，这儿要你们统一维护否则就呵呵了。。

Tip3 关于代码风格

我以为这点每一个写的习惯不同可是做为一个Team写的习惯相似一点我以为仍是有点好处的。咱们用的是OC，你们知道OC的特色是变量名又臭又长（美其名是说自解释性）。问题来了就是如何进行空格以及大小括号怎么放还有何时多敲一个回车的问题，这里盗点文章：

关于在哪里空格

麻了吉就一个字：在关键字后面留空格，在逗号（符号）以后留空格

关于在哪里回车

Preferred:

// blocks are easily readable
[UIView animateWithDuration:1.0 animations:^{
  // something
} completion:^(BOOL finished) {
  // something
}];

Not Preferred:

// colon-aligning makes the block indentation hard to read
[UIView animateWithDuration:1.0
                 animations:^{
                     // something
                 }
                 completion:^(BOOL finished) {
                     // something
                 }];

缘由就是OC代码又臭又长，你还冒号对齐，你看代码的时候很容易看飞了，而括号对齐能保证代码不容易看飞！

关于写好一个正常的API接口

Preferred:

- (void)setExampleText:(NSString *)text image:(UIImage *)image;
- (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;
- (id)viewWithTag:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;

Not Preferred:

-(void)setT:(NSString *)text i:(UIImage *)image;
- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;
- (id)taggedView:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;
- (instancetype)initWith:(int)width and:(int)height;  // Never do this.

哥们麻烦放点正常API好很差。一个正常API大概就是汉语里面的主谓宾。还有及物动词不及物动词。。不及物动次记得加上介词。。。。

关于if else应该怎么接

Preferred:

if (user.isHappy) {
  //Do something
} else {
  //Do something else
}

Not Preferred:

if (user.isHappy)
{
    //Do something
}
else {
    //Do something else
}

缘由仍是由于OC代码相对比较长，这么写结构性更好一点。这个组内达成一个标准就行了。

关于如何在代码块中留回车

这里拿的是AF框架作的一个说明，mattt的代码规范我我的仍是很推崇的。

Tip4 关于集合类

Preferred:

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone": @"Kate", @"iPad": @"Kamal", @"Mobile Web": @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingStreetNumber = @10018;

Not Preferred:

NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingStreetNumber = [NSNumber numberWithInteger:10018];

第一种写法的好处仍是简单明了，并且代码更简洁！
字典声明的时候仍是应当写的更人性化一点好比：

NSDictionary *productManagers = @{
                                  @"iPhone": @"Kate", 
                                  @"iPad": @"Kamal", 
                                  @"Mobile Web": @"Bill"
                                  };

Tip5 关于OC中的结构体及其属性

我相信不少人喜欢这么写：

CGRect frame = self.view.frame;

CGFloat x = frame.origin.x;
CGFloat y = frame.origin.y;
CGFloat width = frame.size.width;
CGFloat height = frame.size.height;

这样写固然OK了，可是看上去代码很累赘，更倾向这种写法：

CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);

多用点C函数可使代码整洁点。

RW的代码规范中强调了不该该使用结构体声明，其实我以为挺好，好比：

CGRect frame = (CGRect){ 
                        .origin = CGPointZero, 
                        .size = frame.size 
                        };
CGPoint point = (CGPoint){ 
                          .x = 5, 
                          .y = 6 
                          };

我不以为这种赋值影响可读性。。我以为可读性会好一点吧....

Tip6 关于段注释

我的不太喜欢在.m中写太多的注释，由于我以为ViewController中的代码分段大概都是类似的。
这里仍是给出AF的段注释来给说明：

#pragma mark -

这个只是一个分割线的效果，通常一个文件有多个@implementation的时候使用

#pragma mark - 段索引

这个是分割线带了概述
截个AF的图来讲明：

这是说下概述特么不是乱写的，正确的概述写法在按住CMD键鼠标左键点击的时候是能够进行跳转的，规范标准仍是以可以跳转为主！

Tip7 关于告警

麻了吉一个字不要留告警，采起任何的手段把告警去掉。。。由于实在看的难受。。。。不要吐槽哥。。

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wassign-enum"
        if (alpha == kCGImageAlphaNone) {
            bitmapInfo &= ~kCGBitmapAlphaInfoMask;
            bitmapInfo |= kCGImageAlphaNoneSkipFirst;
        } else if (!(alpha == kCGImageAlphaNoneSkipFirst || alpha == kCGImageAlphaNoneSkipLast)) {
            bitmapInfo &= ~kCGBitmapAlphaInfoMask;
            bitmapInfo |= kCGImageAlphaPremultipliedFirst;
        }
#pragma clang diagnostic pop

其余去除告警的关键字（"-Wassign-enum"）请谷歌。。。去掉告警的时候有必要请同步组内成员！