编程规范推荐
1.命名风格推荐
1.1 如果使用到了设计模式，建议在类名中体现出具体模式。
<font color=orange>说明：</font> 将设计模式体现在名字中，有利于阅读者快速理解架构设计思想。
<font color=green>正例：</font>
class OrderFactory {
//do something
}
class LoginProxy {
//do something
}
class ResourceObserver {
//do something
}
2.常量定义推荐
2.1 不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类：CacheConstants下;系统配置相关的常量放在类：ConfigConstants下。
<font color=orange>说明：</font> 大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
<font color=orange>注意：</font> 现在多数php框架都有指定的常量类，若使用这些框架，请务必注释上常量的功能及用途，有利于后期维护
3.代码格式推荐
3.1 没有必要增加若干空格来使某一行的字符与上一行对一个位置的字符对齐。
<font color=green>正例：</font>
$a = 3:
$b = 4;
$cd = 5;
$client = new Client();
<font color=orange>说明：</font>增加client这个变量，如果需要对齐，则给变量a、b、cd都增加几个空格，在变量比较多的情况下，是一种累赘的事情。
3.2 方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。
<font color=orange>说明：</font>没必要插入多个空行进行隔开。
3.3 类内方法定义顺序依次是：公有方法或保护方法>私有方法>getter/setter方法。
<font color=orange>说明：</font>公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是『模板设计模式』下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为方法信息价值家底，所有的getter/setter方法放在类体最后。
3.4 setter方法中，参数名称与类成员变量名称一致，this.变量名 = 参数名。在getter/setter方法中，不要增加业务逻辑，增加排查问题的难度。
<font color=red>反例：</font>
public function getS()
{
if (true) {
return $this->s + 10;
} else {
return $this->s - 10;
}
}
3.5 final可以声明类、方法，下列情况使用final关键字：
1）不允许被继承的类。
2）不允许被重写的方法。
3.6 类成员与方法访问控制从严：
1）如果不允许外部直接通过new来创建对象，那么构造方法必须是private。
2）类非static成员变量并且与子类共享，必须是protected。
3）类非static成员变量并且仅在本类使用，必须是private。
4）类成员方法只供类内部调用，必须是private。
5）类成员方法只对集成累公开，那么限制为protected。
4.控制语句推荐
4.1表达异常的分支时，少用if-else方式，这种方式可以改写成：
if ($condition) {
//do something
return $obj;
}
//接着写else的业务逻辑代码
<font color=orange>说明：</font>如果非得使用if()...else if()...else...方式表达逻辑，避免后续代码维护困难，请勿超过3层。
<font color=green>正例：</font>逻辑上超过3层的if-else代码可以使用卫语句，或者状态模式来实现。卫语句示例如下：
public function login()
{
if (isset($a)) {
echo 'set a';
return;
}
if (isset($b)) {
echo 'set b';
return;
}
echo 'not set a and b';
return;
}
4.2除常用方法（如getXxx/isXxx）等外，不要在条件判断中执行其他复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
<font color=orange>说明：</font>很多if语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？
<font color=green>正例：</font>
$a = $abc == null && $b != null && ($c = 1 ? true : false);
if ($a) {
//do something;
}
4.3循环体中的语句要考量性能，以下操作经理移至循环体外处理，如定义对象、变量、获取数据库链接，进行不必要的try-catch操作（这个try-catch是否可以移至循环体外）。
5.注释规约推荐
5.1与其"半吊子"英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
<font color=red>反例：</font>"TCP连接超时"解释成"传输控制协议连接超时",理解反而费脑筋。
5.2代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
<font color=orange>说明：</font>代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
6.日志规约推荐
6.1谨慎地记录日志。生成环境禁止输出debug日志；有选择地输出info日志；如果使用warn来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
<font color=orange>说明：</font>大量输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
6.2推荐使用monolog，它能方便的将日志发送到文件、socket、数据库、收件箱等。规范的日志输出便于对日志进行集中管理，建立如ELK等日志分析平台，方便实时查询日志。
7.MYSQL数据库规约推荐
7.1表的命名最好是加上"业务名称_表的作用"。
<font color=green>正例：</font>
dyw_cqrcb_user/dyw_cqrcb_outlets/dyw_cqrcb_job
7.2如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。
7.3字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：
1）不是频繁修改的字段。
2）不是varchar超长字段，更不能是text字段。
<font color=green>正例：</font>用户登录名使用频率高，字段长度短，用户不能修改登录名，可在相关联的表中冗余存储登录名，避免关联查询。
