PHP开发规范分享

色粉盒撒娇

　　　　一、规范说明
　　
随着公司的发展，项目数量、项目规模及项目人员都发展起来了。但是相应的规范并没有建立起来，每个项目人员都遵守自己的一套规则，没有统一的机制和流程去遵守，导致项目越来越臃肿，维护成本越来越大，开发越来越难。影响公司后期和长远的规划与发展。无规矩，不成方圆。我们是一个集体，是一个团队，在遵守开发人员的独立性的同时，我们应当有相应的统一性的硬性规定，对于我们开发团队来说，即规范。
　　二、开发理念
　　
简单、快速、敏捷
　　三、开发原则
　　
A、 安全第一、性能优先
　　
B、 可用性、可维护性、可扩展性
　　
C、 责任、使命、结果
　　四、开发工具
　　
开发人员的开发工具尽量统一，这样可以统一部署、统一维护。可以保持代码风格的统一性。程序易维护、易阅读. 编程工具：zend studio (便于重构、效率高、功能多、统一部署);辅助工具 Ediplus
　　五、命名规范
　　
命名是以不以数字开头的，采取得 26 个英文字母、10 个数字和下划线组成的，命名应间单，通谷易懂。方便开方人员之间的交流及维护。 原则：观其名，知其义。
　　
A、 变量命名:采取驼峰式法则,通过变量名我们应知道变量的范围，变量要做的事，变量的类型。
　　
1、 全局变量：$gUserId,g 是 global 的缩写,g 后面紧跟着驼峰式的变量名,不过变量名首字母大写,缩写为小写。
　　
2、 静态变量：$sBusRouter,s 是 static 的缩写,s 后面紧跟着驼峰式的变量名,不过变量名首字母大写,缩写为小写。
　　
3、 局部变量：$lThreadId,l 是 local 的缩写,l 后面紧跟着驼峰式的变量名,不过变量名首字母大写,缩写为小写。
　　
4、 配置变量：配置变量是来自于配置文件中的变量，可能有其特殊性。以配置名开头，连接下划线, 后面紧跟着驼峰式的变量名,$db_config。
　　
5、 普通变量：$appInfo 驼峰式的变量名。
　　
6、 参数变量：是指函数参数的变量，function(array $A, Exception $e, $iAge);如果参数可以用类型表示，尽量用类型表示，如变量$A是数组，如果不能用类型表示的尽显用类型间写+参数名。如$iAge表示是整型的，i 是整型缩写。
　　
Int->i,float->f,double->d,string->str,Boolean->b
　　
7、 常量定义：常量名全部用大写，用下划线连接，简单易懂。比较难记难懂的值、 全局通用但不更改的的值尽量用常量。
　　
1 表示用户审核状态,通过WHOLESALE_USER_STATUS_CHECK 简单易懂 define(“WHOLESALE_USER_STATUS_CHECK”, 1);
　　B、 函数命名：采取驼峰式法则，尽量能够表达函数要做的事情，尽量使用动宾结构

　　
1、 全局函数:gGetUserInfoByUid();g是global的缩写,g后面紧跟着驼峰式的变量名,不过变量名首字母大写。从函数名的信息可以知道，我们是通过用户>　　
2、 局部函数:checkUsername();驼峰式法则
　　C、 类的命名：采取驼峰式法则，尽量能够表类的职责，是提供服务，接口，还是封装等。
　　
1、 抽象类：ADbAdapter,a 是 abstaract 的缩写。A 后面紧跟着驼峰式的变量名,不过变量名首字母大写。缩写是大写。DbAdapter 是表示是适配器，提供统一接口的功能。
　　
2、 具体类：userService。驼峰式法则，该类的职责提供统一的用户服务。
　　
3、 静态类：SWindDate。S 是 static 的缩写。S 后面紧跟着驼峰式的变量名,不过变量名首字母大写。缩写是大写。
　　
4、 类属性：同普通变量和静态变量命名规则
　　
5、 类方法：同普通方法和静态方法命名规则
　　
6、 类常量：全部大写，不同词干部分下划线分隔
　　D、 接口命名：大写和驼峰式法则
　　
1、 接口名：IList,I是 interface 的缩写, I后面紧跟着驼峰式的变量名,不过变量名首字母大写。缩写是大写。List是表示集合。
　　E、 文件命名：驼峰式法则，区分大小写，方便 linux 平台部署。
　　
1、 类文件：类名.class.php，如 user.class.php。
　　
2、 配置文件：配置名.config.php，如db.config.php。
　　
3、 普通文件：功能名.php,如 index.php,profile.php。
　　
4、 缓存文件：缓存名.cache.php，如 info.cache.php。
　　
5、 模板文件：前端定义
　　
6、 控制文件：功能名+Controller，功能名首字母大写，如 SiteController。
　　
7、 业务逻辑文件：逻辑名+Model, 逻辑名首字母大写，如 formModel
　　六、代码风格
　　
A、 空格，
　　
1、一元操作符如“!”，“++”，“–”，“~”，“&”等前后不加空格。
　　
2、逗号之后要保留空格，如($a, $b, $c)。如果分号不是一行的结束符号，其后要留空格，如for($i=0; $i这类操作符前后不加空格。
　　
6、字符串连接符“.”前后要加空格 $a = $b . $c;
　　
B、 空行，良好的空行，可以使代码结构优美，逻辑结构清析。我们在不同的控制、条件、循环、函数、类、接口上使用空行，同时在代码体内不同的逻辑结构处使用空行， 逻辑上密切相关的语句之间不加空行。 一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释 减少文件中不必要的空行和注释，让代码清晰、美观、整洁。
　　不同代码块
　　

　　
Function check(){ If($a > 0){ } //空行 If($b>0){ } //空行 Foreach($array $key as $value){ } } //空行 Function ok() { }
　　

　　同一代码块不同逻辑
　　

　　
Function check($uid,$gid){ $uid=(int)$uid; $userInfo =getUserByUid($uid); $userInfo=filterUser($userInfo); //空行 $gid=(int)$gid; $group=getGroupInfo($group); $group=check($group); //空行 $merge=checkMerge($userInfo,$group); }
　　

　　D、 对齐
　　
“｛”和“｝”遵循传统的LINUX的括号规则。首括号与关键词同行，尾括号与关键字同列，｛｝之内的代码块使用制表符缩进，如下所示。 If(!($uid=(int)$uid) && $uid){
　　$userInfo = getUserInfo($uid);
　　
}
　　E、 条件语句
　　
If、while、for、foreach、witch等语句自占一行，执行语句不得紧跟其后，不论执行语句有多少都要加括号,这样可以防止书写失误。
　　七、注释规范
　　
代码注释是硬性规定，听说代码注释是衡量一个优秀程序员的指标之一哟。～ 注释使用进行块注释，//进行行注释
　　
A、 文件注释
　　
　　B、类/接口注释
　　C、函数/方法注释(参数，返回值，长描述，短描述)；短描述必填
　　D、变量/属性注释
　　
1、变量注释 @var 变量名 变量类型
　　

　　
$a = 2;
　　

　　
$b = new WindApc();
　　
2、属性注释 @var 属性类型 属性说明
　　

　　
protected $response;
　　
F、 行注释
　　
1、//$a 是干什么的
　　
$a++;
　　
2、$a++;//$a 是做什么的，优先采取这种
　　
G、 块注释
　　

　　
代码块
　　八、目录规范
　　
A、 文件包含 缓存文件，用 include_once,程序执行文件用 require_once 尽量减少文件包含数，减少磁盘 IO
　　
B、 根目录文件数目必须有限止，在根目录下建立文件要与组长协商
　　
C、 全局文件里修改时，慎重。
　　
D、 目录创建时，要规划好，不要随意创建。
　　
E、供前台访问的 Web 目录结构层次，尽量不要超过三层。
　　九、面向对象
　　
A、 原则
　　
1、“开-闭”原则（Open-Closed Principle,OCP），对扩展开放，对修改关闭。
　　2、里氏代换原则（Liskov Substitution Principle, LSP），任何基类可以出现的地方，子类一定可以出现。
　　3、依赖倒转原则（dependence inversion principle, DIP），依赖于抽象，不要依赖于实现。
　　4、合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP），如果两个类是“Has-a”关系应使用合成、聚合，如果是“Is-a”关系可使用继承。”Is-A”是严格的分类学意义上定义，意思是一个类是另一个类的”一种”。而”Has-A”则不同，它表示某一个角色具有某一项责任。
　　5、迪米特法则（Law of Demeter，LoD），一个软件实体应当尽可能少的与其他实体发生相互作用。
　　6、接口隔离原则（interface separate principle, ISP），使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。
　　B、 设计模式;设计模式是个好东西，但不要套着用，会起反效果的。 具体去看相应的手册吧 Php 中用到比较多的是单例模式、工厂模式、适配器模式、模板方法模式 外观模式、值模式。
　　C、yii框架：会有相应的 yii 框架说明和规范出现，php开发规范只是最基本的。

结束语：希望大家在开发过程中遵守相应的规范，为我们一致的目的努力！当我们看着美观而整洁的代码;清晰明了的程序结构;我们维护程序成本降低了，入手的门槛也降低了，那么轻松的不仅是我们公司，还有我们开发人员吧，为了维护我们美好的程序环境，去遵守吧，哈哈！