代码规范注意事项

类型成员的排列顺序

自上而下依次为：
类中需要声明的类或者结构体
事件：公有事件、受保护事件、私有事件
属性：公有属性、受保护属性、私有属性
字段：公有字段、受保护字段、私有字段
MonoBehavior函数
构造函数：参数数量最多的构造函数，参数数量中等的构造函数，参数数量最少的构造函数方法：重载方法的排列顺序与构造函数相同，从参数数量最多往下至参数最少构造函数与方法的访问级别顺序也应是，公有、受保护、私有。

以上成员顺序的制定思路：一般情况下事件与属性的数量相对较少，如果放置到相对较多的字段后面，也许会出现大片字段与大片函数中间，插入了一个事件，这样是不方便查阅的。并且属性和字段最好是挨在一起。
依据此想法，事件、属性、字段准确的顺序描述应该是，数量较少的应放置到靠前位置。
访问级别顺序的想法是：公有的放前面，方便调用接口的其他用户查阅。也是参照一些插件书写代码的规范得出的结论。

静态成员放在以上所有内容之前，访问级别依然是按照公有、受保护、私有的顺序。

以上方法排序的同时，同一访问级别的成员之间不加空格，非同一访问级别的成员之间才加空格

此规范在项目真实使用的过程中会动态修正。代码规范一定是见仁见智的，但我认为不太完美的规范也一定比没有规范要有效。

 

代码模块划分

不可两个甚至多个程序员维护同一脚本，如若不然必然会出现，我不认识你部分代码的情况。
在此情况下，该脚本的功能职责就会越发的不明确，违背单一职责原则。
这种情况经常会出现的原因，往往是某个脚本的命名涵盖范围太大；
比如说XXXManager，那此时只要是关于XXX的东西恨不得都往这个脚本里面放。
实在实在需要在同一脚本由多人分布式编辑的，使用partial关键字。

代码模块划分一定是以模块本身为单位，而不是人为单位。两个人分别在写各自模块的时候，我要用你的某个接口，如果此接口没有并且此接口很简单，我依然不会在你的模块中自行添加接口，而是喊你来添加这个接口。原因是这个模块的接口最简单的实现方式一定是，写这个模块的人最清楚的，并且模块原作者来添加使得原作者本身对此模块具有更完整的把控。当然，最好的方式是将可能的类似于查改增删这种常用基本的接口，都由原作者与接口需求方提前商讨好，在写模块的时候就已经备好。以后就把模块方称为甲方，接口需求方作为乙方来称呼。自己在写两个独立模块的时候，一定把这两个模块当成两个人分别写的。

一个脚本的行数控制在500行以内，如若不然一定要考虑分多个脚本。

 

一些具体代码中的规范建议

• 公共成员变量命名不能用缩写，哪怕是人人皆知的缩写，例如msg
• 较为复杂公共函数尽量用///三斜杠注释
• static final int CONNECTION_TIMEOUT = 10000    常量名用全大写字母表示，单词间用下划线分割
• if代码段只有一句的情况下，可以不写大括号，代码与if同行
• 委托申明

private delegate void CharacterDie();

pubulic event CharacterDie onCharacterDie;

委托实例在delegate类型之前加on

event的作用是 标识了此关键字的委托实例，外部只能+=或者-=

• 单纯的获取，并且是在不需要参数的情况下，使用属性吧，不要写GetXXX()这样的函数
• Debug或者Throw exception的字符串直接写中文吧
• 类名与函数名用大驼峰命名法，变量名用小驼峰命名法，大小是指开头是大写还是小写。