iOS Objective-c代码规范闲扯
代码规范在软件工程中算是一个老生常谈的话题，在不同的阶段、不同的环境、不同的团队都会产生很大的变化。在这种情况下，很多人会产生认知上的疲倦，写来写去反正看别人的代码不容易看懂，自己也就只能随心所欲的发挥了。但恰恰在这个时候，我们要想提高软件质量和软件开发效率，就必须步调一致，遵守统一的规范，这也就像军队需要纪律和服从一样 。
注意啦：在你编写或维护代码的过程中， 不要因为代码杂乱冗余而心生不满，不要因为代码晦涩而愤怒抓狂，不要因为怕犯错误而心生畏惧。此时，你需要做的是，默默的坐下来理清思路 ，改掉那些低级的逻辑错误，改掉那些模糊不清的命名，改掉那些杂乱无章的文件归类，改掉那些不合常规的结构，重构那些不符合软件设计原则的代码… …。
代码规范事项汇总
目录结构
为什么要设计好的目录结构？
在我看来，软件目录结构就相当于一种规划，是自己对所开发软件的整体认知，这样我们在进行软件结构设计的时候就有一个明确的方向和目标。
当然，软件目录结构没有具体的定式，更何况工程师还有高、中、初之分呢 ？，这些都将因人而异。或许你会认为目录结构不重要，能让程序Work起来OK，不是问题的问题就不是问题；或许你会认为好的目录结构能更好的纵观全局，能更好的控制程序结构，使其具有更高的可读性。
废话少说，不管你对软件有多么高的认知和水平，至少软件目录的结构设计要满足两点吧，可读性和可维护性：
1、可读性：不熟悉当前软件项目的人，通过软件目录结构可以大体了解软件的层次划分、软件的模块划分、软件的核心功能、软件的资源分布情况等，从而快速的切入项目进行开发工作。
2、可维护性：随着软件开发复杂度的增加，软件维护是少不了的，通过软件目录结构可以快速的定位目标文件，明确的知道该在什么目录下新增什么文件，从而使得项目结构时刻保持清晰和组织良好。
目录结构分类
在目录结构设计的过程中，特别注重的是文件的分类，什么地方该放什么，什么地方不该放什么，什么时候需要增加新的分类，这些都是不一而足的，根据项目需要而定。下面列出一些基础的目录结构：
1、Models (模型)：某一功能模块下所用到的模型类文件；
2、Views (视图)：某一功能模块下所用到的视图类文件；
3、ViewControllers (视图控制器)：某一功能模块下所用到的视图控制类文件；
4、Utils (工具类)：网络工具、图片处理工具、测试工具、日志工具；
5、ThirdParty (第三方类/库)：不能通过Cocoapods进行管理的，需要单独归类；
6、Configs (配置)：一些本地或第三方常用的配置参数；
7、Micros(宏定义)：应该是整个应用会用到的宏定义，尽量少用；
8、Cocoapods(第三方库)：尽量使用代码依赖管理工具(Cocoapods)，并阶段性实时更新；
9、Resources (资源管理)：存放App会使用的一些资源(图片、音视频等)；
10、Docs (文档)：相关软件设计文档，记录软件开发过程中重要的结构设计。
以下为不合理的目录结构，各种内容混杂，分得太细，看起来太累：
目录结构命名
在设计目录结构的工程中，经常看到第一字母大写、全大写、全小写、带中文等文件命名，看上去颇为不协调，怎么看怎么别扭。在此，为了更好的保持目录结构的整洁，统一软件目录结构的命名方式，命名规则如下：
1、名称具有名词属性，不能使用动词或语句；
2、只能使用英文描述，不允许其他文字出现；
3、每个单词第一个必须字母大写，单词数不能超过3个；
4、所命名目录不能产生歧义，让其他开发人员不明所以；
5、避免人为缩写，除非是在软件行业或英文中认可的缩写。
以下为不合理的目录命名方式：
类设计
任何设计都源于生活
一棵草、一棵树、一座山、一条河…，它们中的每一个都是独立的存在，关联在一起又是完美的组合。想到什么了吗？我只想说，设计源于生活，如果你的生活是有井井有条的，那么你的人生将会是完美的。
生活源于秩序
一个类代表一类事物，明确它具有什么属性和行为，不要有多余的内容，就好比不能在人的身上加尾巴一样。
1) 单一职责原则
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
2) 开闭原则
开放扩展、关闭修改，它是软件可维护、可扩展、可复用、灵活性好的基础。我们首先要抓住软件中表现的共性或频繁变化的部分，然后对其进行抽象 。
3) 依赖倒转原则
这里主要涉及到模块之间的依赖关系，尽量减少类之间的依赖。也就是一句话的事情，抽象不依赖细节，细节依赖于抽象。
4) 里氏替换原则
任何基类可以出现的地方，子类一定可以出现，反过来则不可以。
5) 接口隔离原则
使用者只依赖于它需要的接口，需要什么接口就提供什么接口，把多余的接口剔除掉。
6) 迪米特法则
类与类相互之间知道得越少越好。也就是说，至少要做到金玉其外(表面谦谦君子)，败絮其中(内心阴险邪恶)吧。当然，内外间修是我们的目标啦。
注：多看点设计模式(大话设计模式、设计模式之禅)吧，好处多多。
头文件
我认为，头文件的作用在于对外界的表达，让别人很方便的了解这个类的行为和属性是什么，从而展现出最为优良的一面(该露的地方一定要大方的露出来，不该露的地方则要隐藏起来，任何人都找不到)。
属性
对外暴露的属性，要具有实际的操作意义，不能为了方便而方便。在添加属性的时候，特别需要考虑它在实际场景中的应用是不是必须的，能不能很好地告诉外界这个属性的功能及作用是什么。设计规则如下：
1) 良好的名称
一般采用小驼峰命名法(第一字母小写)，名称要具有名词属性，不能使用动词或语句。
2) 不能有歧义
在命名时，用词要准确，不能产生误解，如果实在找不到合适的词来描述，那么加上一些其他词来辅助。比如运动场地类型：fieldType(我还以为是字段呢)，或许sportFieldType会更好一点。
3) 必须暴露吗？
在类内部使用的属性是完全没有必要暴露的。那么这部分属性就一定不能放在头文件中，不能让外界看到这些无用的属性。
下面的属性放在头文件显然不合适(单词拼错、语义表达不清)：
方法
一个类的对外(public)方法，是一种特定的行为表现，反映了其对外界的交互能力(什么样的输入，产生什么样的输出)。设计规则如下：
1) 函数名
具有动作属性，命名方式采用动名词结合的方式。
2) 清晰的参数名称
具有名词属性，表达清晰、用词准确。
3) 合适的参数个数
一般参数个数不能超过5个，否则需要进行拆分或者组合。
4) 合理的参数顺序
参数顺序要按照常规的思维逻辑进行编排，不能随心所欲。
5) 恰当的返回值
通过方法行为来判断，返回值应该是bool、int还是其他，不能混用。
下面的方法设计，就有点让人摸不着头脑：
委托
委托，顾名思义就是自己做不了，而需要提供需求让别人来完成的事情(有点像包工头)。 设计规则如下：
1) 自己的事情自己做，必须别人帮忙的时候才让别人做。
2) 遵循“头文件—方法”中方法命名、参数命名、参数个数、参数顺序、返回值规则。
源文件
外表我们该化妆的已经化妆了，至少第一印象已经证明你是一个才华出众、风度翩翩的君子啦，但不要一开口就打回流氓地痞的原型，很丢人的，我们要做到内外兼修啊。
变量命名
命名方式
我们在声明成员变量的时候，尽量做到简单易懂，最好在名称之前加上必要的分类前缀，因为现在的编译器都有代码补全的功能，这样我们就可以很容易找到我们需要的变量。在此，举几个例子：
1) UILabel类型：UILable*lblName;
2) UIButton类型：UIButton*btnLogin;
3) UITextView类型：UITextView*txtMail;
4) NSInteger类型：NSIntegernAge;
5) NSString类型：NSStringstrNickname；
一般规则
见过变量声明和变量使用间隔几十上百行代码吗？是的，我见过，也就是天一句地一句的感觉，非常不妙。在此，我们必须遵循的规则是“就近原则”，也就是什么地方使用什么地方声明。
方法设计
方法定义
遵循“头文件—方法”中的方法命名、参数命名、参数个数、参数顺序、返回值规则。
方法实现
有的时候看到一个函数有几百行乃至上千行，各种全局变量满天飞，部分变量还命名不清，瞬间眼花，真是欲哭无泪啊。这就有点类似于写了几千字的作文，没有缩近，没有分段，你还有读下去的勇气么？反正我是没有滴。一般约束如下：
1) 通过传参的方式使用变量，尽量少的直接使用外来变量；
2) 尽量做到什么地方使用变量，什么地方声明；
3) 不同功能类型的数据操作使用空行隔开；
4) 条件判断语句尽可能少用；
5) 函数代码行数最好不要超过200行；
注释&代码提交原则
代码注释
在我看来，注释就相当于高中语文课本中的文言文，有的词很难从它的表象表达出本身的意思，必须通过注释才能看懂，那么软件注释也应该是这样的。代码注释规则如下：
1) 在命名明确的情况下，就不要去画蛇添足的注释了；
2) 该采用单行注释符号(//)的时候不要使用多行注释符号(/**/)；
3) 废代码坚决干掉，不要畏首畏尾，实际上这是对你本身承担责任的一种考验。
代码提交
代码提交也是一门艺术，不要轻视它，要明确的表达出什么时候、什么人、什么内容、什么版本。一般规则如下：
1) 工作目录要及时更新，不要和SVN服务器有太大差别；
2) 提交代码时，如果发现冲突，必须仔细分析解决，不可以强行提交；
3) 提交代码前，确保软件可以正常运行，不可盲目提交；
4) 提交注释(例)：yidong+ (V1.0.0) + : +提交内容注释。