每个公司有每个公司的代码规范，学习记录下新公司iOS代码规范：
命名
命名规则对于维护代码来说是非常重要的，清晰简洁的命名有利于团队合作 。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义。以下是命名的细则：
1.1.命名不要使用通用的模糊的命名，准确命名，不要缩写简写命名或用单个字母命名。
1.2.命名优雅：参考Almofire中 public func stream(withHostName hostName: String, port: Int) -> StreamRequest 。
1.3.类型命名都是以大驼峰命名，变量和常量使用小驼峰命名。不要使用任何匈牙利标识法（ Hungarian notation ）命名（例如：k为常量，m为方法），应使用简短的命名并且使用 Xcode 的类型 Quick Help (01.png+ click) 去查明变量的类型。同样地，不要使用小写字母+下划线（ SNAKE_CASE ）的命名方式。
1.4.命名中避免重复的词语，可参照swift官方文档规定，如下：
// Swift 3 definition
prepare(for segue: UIStoryboardSegue, sender: Any?)
// Swift 3 calling code
viewController.prepare(for: segue, sender: something)
1.5.func命名中含有默认值的参数放在最后。
1.6.定义每个func传入、返回参数标签的格式，尽量按照swift规范格式来写，如此代码结构更加清晰，方便自己和别人维护阅览。
{例如：
(message : T, file : String = #file, lineNumber : Int = #line, FuncName: String = #function)
而非
(message:T,file:String=#file,lineNumber:Int=#line,FuncName:String=#function)
注意空格、逗号、冒号，以及换行，特别是空格！
}
1.7.图片名称应该被统一命名以保持组织的完整。它们应该被命名为一个说明它们用途的驼峰式字符串，其次是自定义类或属性的无前缀名字（如果有的话），然后进一步说明颜色 和/或 展示位置，最后是它们的状态。例如：
RefreshBarButtonItem / RefreshBarButtonItem@2x 和 RefreshBarButtonItemSelected / RefreshBarButtonItemSelected@2x
ArticleNavigationBarWhite / ArticleNavigationBarWhite@2x 和 ArticleNavigationBarBlackSelected / ArticleNavigationBarBlackSelected@2x.
方法
2.1. 构造方法 可直接使用类名+.形式调用例：NoticeinfoModel(responseData: JSON) 不需要写init ( NoticeinfoModel.init(responseData: JSON) ) 。
2.2. 当在解析时网络框架将转成 SwiftyJSON 所以 解析时 尽量用 stringValue 防止数据为空 。
类代码组织原则
一个原则：析构函数deinit 最好放到类最上面，第一眼就可以看到这个方法，可以方便看到是否remove了一些操作，对内存的合理释放等，controller，view的生命周期函数放到最上面，自己实现的方法在下面，相同/相近功能的方法采用#pragma mark -来标记，以便查看。
注释
当需要的时候，注释应该被用来解释 为什么 特定代码做了某些事情。所使用的任何注释必须保持最新否则就删除掉。
通常应该避免一大块注释，代码就应该尽量作为自身的文档，只需要隔几行写几句说明。这并不适用于那些用来生成文档的注释。
3.1.有些闭包无法体现其功能的需加注释。
3.2.model中的变量需要添加注释。
3.3.服务器返回的枚举类型需加注释，不要使用magic number来标识一个变量的值。
文件结构
iOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有效地管理类文件。在实际中使用中，项目实际负责人可以结合项目特点灵活使用，但基本的原则一定要保持，保持良好的类文件组织结构。
4.1. 建议一个文件不要超过1500行。
4.2. 建议一个函数或者方法不要超过一屏。
4.3. 无用的代码，包括Xcode生成的模板代码和占位符注释应该删除，除非是有目的性的保留这些代码。一些方法内只是简单地调用了父类里面的方法也需要删除。
4.4. contorller里view建议抽出来，view里不要耦合model。
4.5. view中的控件建议使用私有来修饰，使用方法去修改view中的控件的值。
4.6. 使用MARK进行代码的分段，结构清晰。
Swift使用规范
5.1. 为了保持简洁，可以避免使用 self 关键词。
5.2. 空格的使用参照标准的apple sample code，统一使用。
5.3. 合理的使用private 和 fileprivate, 推荐使用private，在使用extension时可使用fileprivate。
5.4. 当不确定数据是否为空时可用 ?? 方式 例如 print(str ?? “")。
5.5. 优先使用Swift原生类型，可以根据需要使用Objective-C提供的方法。
5.6. 仅在闭包表达式参数在参数列表中最后一个时，使用尾随闭包表达式。闭包参数命名要有描述性。
5.7. 使用数组时 可指定元素类型 例：var noticeArr = [JSON]() 如不需要实例化则 var noticeArr : [JSON]? 。
5.8. 单例使用shared(不要使用shareInstance，shareClient之类的其他名字)。
Xcode工程
6.1. 使用showInFinder形式去真正创建文件，拖进project中。
6.2. xcassets中根据项目模块结构方式添加对应的文件，不要单独把图片拖进xcassets中，删掉图片需要在xcassets中delete删掉，保证图片对应的json也删掉。
6.3. 为了避免文件杂乱，物理文件应该保持和 Xcode 项目文件同步。Xcode 创建的任何组（group）都必须在文件系统有相应的映射。
6.4. 为了更清晰，代码不仅应该按照类型进行分组，也可以根据功能进行分组。如果可以的话，尽可能一直打开 target Build Settings 中 “Treat Warnings as Errors” 以及一些额外的警告。如果你需要忽略指定的警告,使用 Clang 的编译特性 。