我的代码习惯

一直以来我都坚持团队合作里面要有一份编码规范，尽量保持编码的一致性，让代码更清晰，便于代码审查和团队合作。即使迫于某些原因无法普遍的实施，但也要严格要求自己。
自己写的代码不仅仅是对项目，对自己负责，也要对他人负责。正常来讲在自己的写的东西在特定阶段会有其他人参与，也会被其他人接手，为了不被后来人骂的太惨，还是要保持良好的编码习惯。

代码规范

代码规范不是自己凭空想像的，主要还是参考了各家的代码规范，外加自己的实践。自己遵守的代码规范，主要参考Objc Zen Book。当时在火车上一口气看完，看完即决定就是它了。之前已有整理，详见《禅与Objective-C 编程艺术》笔记。接下来我再挑一些比较重要的来讲。

代码组织

分组

• 推荐使用属性。除了init和dealloc方法,应该总是使用.语法访问属性，如果getter方法里进行了初始化和其他操作，init方法里也应该使用.语法。
• 善于用#Pragma Mark进行代码分组。
• 私有方法添加p_前缀进行区分，但不要以下划线_开头。
  [站外图片上传中...(image-253e0f-1533479745573)]
  这样分组主要依据是涉及逻辑和经常变化的部分越靠前。ConfigViews和Init部分属于配置和布局，一个很少更改，二是手动布局代码量可能会很多，因此放到最后。这样我们在查看.m文件是更多的去关心这部分的业务逻辑。

语句总是使用大括号包围，以避免错误

推荐

if (!error) {
   return success;
}

不推荐

if (!error)
return success;
或者
if (!error) return success;

nil和BOOL检查使用感叹号！来判断

因为nil是解释到NO所以没必要在条件语句里面把它和其他值比较。同时，不要直接把它和YES比较，因为YES的定义是1而BOOL是8位的，实际上是char类型。

推荐

if (someObject) { ...
if (![someObject boolValue]) { ...
if (!someObject) { ...

不推荐

if (someObject == YES) { ... // Wrong
if (myRawValue == YES) { ... // Never do this.
if ([someObject boolValue] == NO) { ...

三元运算符?:,应该只用在它能让代码更加清晰的地方

推荐

result = a > b ? x : y;
result = object ? : [self createObject]; // 第二个参数返回和条件语句中已经检查的对象一致时

不推荐

result = a > b ? x = c > d ? c : d : y;
result = object ? object : [self createObject]; // 第二个参数返回和条件语句中已经检查的对象一致时

当switch语句里使用可枚举的变量的时候，default是不必要的，没有default有利于错误的排查

switch (menuType) {
    case ZOCEnumNone:
        // ...
        break;
    case ZOCEnumValue1:
        // ...
        break;
    case ZOCEnumValue2:
        // ...
        break;
}

关于遍历

多用快速遍历（for in）或者block的方式遍历,少用常规for循环。

Enumerated Types枚举类型

• 推荐使用NS_ENUM()声明。
• 用枚举表示状态，选项，状态码，可读性和可用性会大大增加。

常量

• 多用类型常量，少用#define预处理指令，有利于错误检测。
• 类型常量如果在类外可见，则应该在.h文件中使用extern声明。

命名

• 使用驼峰命名法
• 单词直接不使用_连接。
• 多个参数时使用描述性关键词，不使用and等连接词来表明多个参数。

多使用字面量来创建不可变的实例对象。

推荐

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

注释

秉承好的代码不需要注释来规范命名。但是一下几点推荐注释。

• .h 头文件中推荐声明该类的作用
• 接口方法应该有注释
• 如果变量或方法名不明确的应该加上注释
• 待完善部分申明TODO:
• 在需要的地方使用#warning和#error提示

美化代码

• 方法的大括号和其他的大括号(if/else/switch/while 等) 总是在同一行开始，在新起一行结束。

  推荐:

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

  不推荐:

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

• 方法命名在方法类型（-/+符号）后应该有一个空格。

• 方法之间应该要有一个空行来帮助代码看起来清晰且有组织。 方法内的空格应该用来分离功能，但是通常不同的功能应该用新的方法来定义。

• 优先使用 auto-synthesize。但是如果必要的话， @synthesize and @dynamic。

• 应该总是让冒号对齐。有一些方法签名可能超过三个冒号，用冒号对齐可以让代码更具有可读性。即使有代码块存在，也应该用冒号对齐方法。

  推荐：

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

接口设计

• 类加上前缀，避免命名空间冲突。
• 类的头文件（.h）中尽量少引入其他头文件，避免互相引用，降低耦合，减少编译时间。如需引入类，使用前向声明（@class）
• 尽量创建不可变对象，不要把可变对象属性公开，而是提供相关方法。
• 属性如果有读写权限设定，需要用readonly声明
• 方法命名要清晰，尽量不使用缩略词

善用代码片段

code snippet

使用Assets管理图片

• slicing
• render

结合其他工具使用，提高效率

• vscode
• SourceTree
• Go2Shell
• iTerm2
• simsim
• Sequel Pro
• AppCode