PHP编码规范

8.1.命名规约
8.1.1.[强制]所有编程相关命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例： _name / __name / $Object/nam{e}_{/}name$ / Object$

8.1.2.[强制]类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名）DO / DTO / VO / DAO/MODEL等。
正例：MarcoPolo / UserDO / XmlService / TaPromotion
反例：macroPolo / UserDo /XMLService / TCPUDPDeal / TAPromotion

8.1.3.[强制]方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。
正例：localValue / getHttpMessage() / inputUserId

8.1.4.[强制]常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
正例： MAX_STOCK_COUNT
反例： MAX_COUNT

8.1.5.[强制]抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。

8.1.6.[强制]POJO类中的任何布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型boolean isSuccess；的属性，它的方法也是isSuccess()，RPC框架在反向解析的时候，“以为”对应的属性名称是success，导致属性获取不到，进而抛出异常。

8.1.7.[强制]文件名应该根据所使用的框架要求，如果无要求，文件名应该与类名保持一致，包括大小写，而文件后缀也应该保持统一。点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例： 应用工具类包名为Base.class.php、类名为Base（此规则参考spring 的框架结构）

8.1.8.[推荐]如果使用到了设计模式，建议在类名中体现出具体模式。
说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计思想。
正例：public class OrderFactory; public class LoginProxy; public classResourceObserver;

8.1.9.[推荐]接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名： func();
常量：CONAT COMPANY = ‘define’;
反例：接口方法定义：public abstract fun();

8.1.10.接口和实现类的命名有两套规则：
1） [强制]对于Service和Dao类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。
正例：CacheServiceImpl实现CacheService接口。
2） [推荐] 如果是形容能力的接口名称，取对应的形容词做接口名（通常是–able的形式）。
正例：AbstractTranslator实现 Translatable。

8.1.11. [参考]枚举类名建议带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开
说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。
正例：枚举名字：DealStatusEnum；成员名称：SUCCESS / UNKOWN_REASON。

8.1.12.[参考]各层命名规约：
A) Service/DAO层方法命名规约
1） 获取单个对象的方法用get做前缀。
2） 获取多个对象的方法用list做前缀。
3） 获取统计值的方法用count做前缀。
4） 插入的方法用save（推荐）或insert做前缀。
5） 删除的方法用remove（推荐）或delete做前缀。
6） 修改的方法用update做前缀。
B) 领域模型命名规约
1） 数据对象：xxxModel，xxx即为数据表名。
2） 数据传输对象：xxxDao，xxx为业务领域相关的名称。
3） 展示对象：xxx.html，xxx一般为网页名称。
4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPoJo。

8.1.13.[强制]php的关键字必须小写，包括但是全局变量除外，关键词包括语法词汇，和系统方法名，注意：如果系统方法名是大写，就按照系统要求。

8.2.注释规约
8.2.1.类的注释规范：

8.2.2.方法的注释规范：

8.2.3.重点的注释规范：

8.2.4.单行的注释规范：

备注：根据不同的使用场景，采用不同的注释风格,其他语言都支持//单行注释，但是由于
我们常用的语言是php,所以建议使用#脚本注释，单行注释再很多时候，不太美观。

8.3 编程规约
8.3.1.[强制]所有变量使用前，必须要声明并且赋默认值。根据不同的类型，需要设置不同的默认值，如果不清楚默认类型，需要设置null,null可以设置为一切类型的起始值。

8.3.2.[强制]在实现一个方法或者函数时，采取排除法的方式判断代码，不要嵌套过多层次的if,增加代码的可读性，把最有可能性的判断写在最前面，讲所有情况都满足的条件情况，写在最下边。

8.3.3.[强制]优先使用php内置函数，或者框架内置方法，减少自己不必要的实现，这
个无法举例，需要根据实际业务需求来判别。

8.3.4.[推荐]减少else的使用，适当情况下，采用默认值，或者三元运算，去掉多此一举
的if判断。

8.3.5.[推荐]由于代码的执行顺序，使用逻辑运算符和短路语法，来精简代码。

8.3.6. [参考]使用赋值数据来，代替switch或者if，精简代码

8.3.7 [推荐]多个if和else时，采用switch判断

8.3.8 [推荐]合理的使用循环
• 循环体内尽可能不用函数或更耗资源的调用
• foreach代替while和for循环（PHP）
• 避免空循环
• 只做一件事,尽可能短，控制在50行以内
• 循环嵌套限制在3层以内
• 不必要的情况下，不要使用&引用符，这个相当于内存指针，如果逻辑不清晰你会混乱
的。

8.3.9 [推荐]合理的书写函数和类方法
• 函数的最佳最大长度是50-150行代码
• 函数参数不超过7个,如果超过7个最好可以使用数据来代替单一参数
• 短小函数更容易理解也方便修改
• 只做一件事情的函数更易于复用
• 短小的函数测试更方便

8.3.10 [推荐]类，方法，函数，代码块的开始和结束，有些习惯换行，有些习惯不换行，但是我个人认为不换行，更省代码；[强制]所有左花括号 { 都不换行，并且 ｛ 紧挨着的下方，一定不是空行。

8.3.11.[强制]成员方法访问修饰符必须显示声明不能省略。

8.3.12.[推荐]当用到抽象(abstract)和终结(final)来做类声明时，它们必须放在可见性声明(public 还是protected还是private)的前面。而当用到静态(static)来做类声明时，则必须放在可见性声明的后面。

8.3.14.[推荐] if、else、else if、switch、for、foreach、case、while、go、try、catch 等关键词后面必须加空格。可以说，没有特殊说明的情况下，基本上所有的 PHP 关键词后面都必须加空格。流程控制语句起始的花括号是不需要另起一行。

8.3.15.[强制]类名必须要和对应的文件名要一模一样，大小写也要一模一样,但是需要根据不同的框架，具体应用。

8.3.16.[强制]每个人的显示器分辨率不一样。既然不超过一屏也会出现别的同事一屏会超出的情况。所以，即使未超过一屏，也尽量保证代码行在 50 行以内。如果发现自己的代码超过了 50 行，那么就需要考虑自己的代码是不是有拆分不合理的地方。特殊情况允许超过 50 行。但是，整个方法里面的代码必须是简单的判断逻辑。不包含复杂的业务判断逻辑。因为，不同的业务判断最佳实践是单独封装一个方法。

8.3.17.[强制]数组：只有两个以内键值对时写成一行；有多个键值（超过两个）对时换行。

8.3.18.[强制]循环内部尽量不能出现数据库操作,这个可以保证除了脚本之外，以减轻数据库的压力。

8.3.19.[强制]关键词 extends 和 implements 必须 写在类名称的同一行。

8.3.20.[强制]方法或函数的参数也是变量的一种，故与变量的命名风格一致(小驼峰)。

8.3.21.[推荐]控制结构关键词后 必须 有一个空格。
• 左括号 ( 后 一定不可 有空格。
• 右括号 ) 前也 一定不可 有空格。
• 右括号 ) 与开始花括号 { 间 必须 有一个空格。
• 结构体主体 必须 要有一次缩进。
• 结束花括号 } 必须 在结构体主体后单独成行。

8.3.22.[强制] array() 和 [] 是数组使用最为频繁的方式，什么情况下，如果不是必要，使用[]来代替array()方法；

8.3.23 [强制] 使用数组键名取值之前，最好加上isset的判断，然后取值。三元运算取值，也要严谨。

8.3.24 [强制] 使用SQL语句时，所有关键必须大写，表使用别名，也应该大写。

8.3.25 [强制]除了Model层和Dao层之外，所有的SQL语句不能出现在其他层次中。

8.4 层次规约
以下是新版主播的代码层次，可能写起来比较麻烦，但是由于时间仓促，没能好好的归类，导致，接口偏大，文件偏大，我始终认为，逻辑层次应该与控制器和模型分离，好处大家心里都明白，我希望大家至少保证，要抽象出一层单独的服务层，处理业务逻辑。不要把逻辑
写在Controller层和Model层，这两层都不易维护。
◇ models层作为类模型和数据库模型的映射，只处理映射关系，目前没有做；
◇ dao层作为访问具体具体数据的类，提供数据库源请求方式，只是接口；
◇ dao.impl 层对具体的dao层具体实现，同一个dao,可以实现多个impl类；
◇ service层定义业务逻辑的具体方法，只定义接口；
◇ service.impl层对service具体实现，同一个service可以实现多个impl类；
◇ controller层作为数据的参数判断和服务分发类；
◇ libary层保存常用的工具类以及基础的核心类；
◇ plugins层保存第三方插件，和一些第三方的SDK文件（Yaf中是自己的钩子类）；
◇ views层保存一些html静态文件，只输出静态模版，数据操作依赖接口；