PSR-各个框架遵循的统一编码规范现代PHPer的开发规范

不管是什么框架,就拿 ThinkPHP 框架来说,官方文档明确说明:ThinkPHP5.1遵循PSR-2命名规范和PSR-4自动加载规范。这就引出了本篇博文的内容:PSR 是什么?PSR 由谁规定的?

PSRPHP Standards Recommendation的简称,意为 PHP 推荐标准、PHP 开发的实践标准。要想了解 PSR,首先得知道制定这一标准的人/组织是谁:

PHP-FIG

PHP-FIG全称为PHP Framework Interop Group,是一个组织,这个组织的成员由一些 PHP 框架的代表组成,这些人聚在一起“讨论框架之间的共性,寻找可以合作的方式。PHP-FIG制订了推荐规范,PHP 框架可以自愿实现这些规范,改进其他框架的通信和共享功能

PHP-FIG的使命是以最低程度的限制,制定一个协作标准,各个框架遵循统一的编码规范,避免各家自行发展的风格阻碍了PHP的发展

目前已表决通过了 6 套标准,而且已经得到大部分 PHP 框架的支持和认可,如 ThinkPHP、Laravel、Composer 等

PSR-1:基础编码规范

在本篇博文的最开始,我们就已经简单介绍过什么是 PSR,PSR 是 PHP 标准,而 PSR-1 是 PHP 最基本也是最简单的标准

PHP 标签

PHP 代码 必须 使用 <?php ?> 长标签 或 <?= ?> 短输出标签;

一定不可 使用其它自定义标签。

这点相信很多 PHPer 都很容易遵守,而且在现实撸代码中一般都是采用正常的<?php ?>标签,因为如果要使用 PHP 的短标签<?= ?>的话,必须在 php 的配置文件php.ini中找到short_open_tag,开启以后才可以使用 PHP 的短标签,但是这个短标签是不推荐的,使用<?php ?>才是规范的方法,只是因为这种短标签使用的时间比较长,这种特性才被保存了下来

编码

PHP 代码 必须 且只可使用 不带 BOM 的 UTF-8 编码

这个也是很常见,就是无 BOM 和有 BOM 格式,记得刚开始学 PHP 的时候,都会强调不要用记事本打开编辑,一定要搞成无 BOM 格式啊

目的(副作用)

一个 PHP 文件 可以 定义符号(类、性状、函数、常量等),或者执行有副作用的操作(生成结果或者处理数据),但 不能 同时做两件事

这里副作用的意思是:仅通过包含文件,不直接声明类、函数和常量等,而执行的逻辑操作,这个规定的意思差不多就是一个变量、方法或者一个类,只能相应完成一个操作、做一件事情,也就是我们平时撸码的时候,定义变量、方法时最好不要重名,这样保证了代码的清晰易懂,也保证了方法、变量的单一性。比如我们在定义变量的时候定义为同一个变量,在循环中,可能会直接覆盖,得不到你想要的值

自动加载

PHP 的命名空间和类 必须 遵守 PSR-4 自动加载器标准

接着给后面看 PSR-4 的具体解释

类的名称

PHP 类的名称必须使用驼峰式,又名标题式,PHP 5.3 及以后版本的代码 必须 使用正式的命名空间,5.2.x 及之前的版本 应该 使用伪命名空间的写法

驼峰式和分词式这两种写法,驼峰式就是ShenYan这样式的,分词式就是shen_yan这样下划线式的

常量的名称

PHP 的常量中所有字母都 必须 大写,词间以下划线分隔

这点应该是没什么可说的吧,最开始写 PHP 的时候,这个写法已经深入人心了

方法的名称

方法名称 必须 符合 camelCase() 式的小写开头驼峰命名规范

方法的命名和类的命名方式有些相似,不过还是有些区别的,类的命名规定首字母大写ShenYan,而方法的命名规定首字母小写shenYan

PSR-2:编码风格规范

PSR-2规范是在PSR-1基本代码规范的继承与扩展,PSR-1 是更为严格的代码规范。开发者应该遵循更为严格的代码标准,在现代的 PHP 生态系统中,风格统一,可以更好的让其他开发者理解 PHP 代码

贯彻 PSR-1

代码 必须 符合 PSR-1 中的所有规范

文件和代码行

所有 PHP 文件 必须 使用 Unix LF (linefeed) 作为行的结束符,所有 PHP 文件 必须 以一个空白行作为结束,纯 PHP 代码文件 必须 省略最后的 ?> 结束标签

对于这个必须省略最后的结束符号平时倒是没注意过,毕竟只写框架中只写开头

缩进

代码 必须 使用 4 个空格符的缩进,一定不可 用 tab 键

对于缩进这个问题,说是必须使用 4 个空格,但是在使用 IDE 或者 Sublime 以及其他编辑器的时候,都是直接按 tab 键的,这都是编辑器所设置好的吧。以四个空格为缩进,这样的话,就算是用不一致的编辑器打开,效果也是一样的,并且使用空格缩进,让对齐变得更方便

关键字 以及 True/False/Null

PHP 所有 关键字 必须 全部小写,常量 truefalsenull必须 全部小写

之前写的 PHP 代码像truefalse这样的关键字好像使用的是大写或者首字母大写,而且很多地方也说NULLTRUEFALSE不区分大小写

命名空间

namespace 以及 use 声明,每个命名空间语句后必须跟着一个空行。类似的,使用 use 关键字声明命名空间或为命名空间创建别名时,在一系列 use 声明语句后要加一个空行

类似于这样

<?php
// 声明本文件的命名空间
namespace My\Friend;

// 导入命名空间
use Other\Friend as O_Friend;

class GirlFrined
{
    
}
// ... 更多的 PHP 代码在这里 ...

类、属性和方法

类定义体的起始括号应在类名之后另起一行写
类定义体的结束括号 必须 在定义体之后新起一行写

每个属性都 必须 添加访问修饰符
一定不可 使用关键字 var 声明一个属性
每条语句 一定不可 定义超过一个属性
不该 使用下划线作为前缀,来区分属性是 protected 或 private

方法定义体的起始括号应在方法名之后另起一行写
方法定义体的结束括号必须在方法定义体之后新起一行写

可见性

类中的每个属性和方法都要声明可见性。可见性由 public、protected 或者 private 指定,其作用是决定在类的内部和外部如何访问属性的方法
私有方法的名称前加上下划线
如果类属性声明为abstractfinal,这两个限定符必须放在可见性关键字之前
如果属性、方法声明为static,这个限定符必须放在可见性关键字之后

// 1、2
public $sex;
private $_sex;
protected $sex;

// 3、
abstract public $sex;
final public $sex;

// 4、
public static $sex;
public static $age;

控制结构

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

每个结构体的主体都 必须 被包含在成对的花括号之中,这能让结构体更加结构话,以及减少加入新行时,出错的可能性

/** 
* 错误的示例:
* 这里有 4 个错误:
* 1、if 关键词后面和圆括号之前没有空格
* 2、圆括号前后有空格
* 3、后圆括号和起始括号之前没有空格
* 4、else 关键词前后没有空格
**/
if( 1 == true ){
    // do something
}else{
    // do something
}

/** 
* 正确的示例:
**/
if (1 == true) {
    // do something
} else {
    // do something
}

PSR-3:日志接口规范

PHP-FIG 发布的第三个推荐规范和前两个不同,这个有点特殊是一个接口,主要目的是为了让日志类库以简单通用的方式,通过接收一个 Psr\Log\LoggerInterface 对象,来记录日志信息

日志记录器是对象,用于把不同重要程度的消息写入指定的输出。记录的消息用于诊断、检查和排除应用中的操作、稳定性和性能方面的问题。例如:开发的时候把调试信息写入到文本文件,把网站的流量统计信息记录到数据库等

PSR-3 规范出来之后,达到这种效果的组件太多了,这里就不介绍,如何实现这个接口的类了

PSR-4:自动加载规范

PSR-4 是由文件路径自动载入对应类的相关规范,比如我们的Composer,PSR-4 推荐规范不要求改变代码的实现方式,只建议如何使用文件系统目录结构和 PHP 命名空间组织代码。PSR-4**依赖**PHP 命名空间和文件系统目录结构查找并加载 PHP 类、性状和接口
为什么自动加载器很重要
举一个很常见的场景,平时我们开始的时候如果不是用框架,想要一个验证码,就要先去 Gihutb 或者其他地方找一个验证码类,然后在项目中 include 一下,再编辑编辑就跑起来了,我们引入文件通常都是采用requireinclude这样的方法,这样的方式简单也可靠,但是如果我们引入一两个还好说,但是当我们一个项目运行时需要引入几十个文件呢,那我们岂不是要写几十个require或者include?这样既不方便,又不美观,所以 PHP-FIG 在此基础上考虑,规范了一个统一的自动加载器策略

如何使用自动加载器

建议使用依赖管理器Composer自动生成的 PSR-4 自动加载器,而且现在的 PHP 框架,laravel、Yii、TP5 等都使用了依赖 Composer 的自动加载器策略,方便我们下载组件和引入合适的类

PSR-ME:制定自己的 PHP 规范

  1. 遵循 PSR-1、PSR-2 的使用规范
  2. 合适、精简的变量、方法、类命名,能让人看一眼就清楚是做什么的
  3. 尽量编写出高内聚、低耦合的代码
  4. 保持代码结构整洁、美观

PHP-FIG 推出的 PHP 规范,并不一定说所有的 PHP 开发者必须遵守,制定这一规范的目的就是为了在全世界的 PHP 开发者在查看代码的时候,能更加简单和轻松。造出来的组件/轮子可以很容易的就被所有开发者熟知和使用,同时也减少了我们的工作投入率,得到更大的工作效率,使产出大于投入,效率更高更快

我今年的目标就是在公司的项目中将 ThinkPHP5 框架熟练,平时找项目练习 Laravel 框架,然后将 Swoole 面向生产环境的 PHP 异步网络通信引擎以及 Yii 框架学会,再入手一个自己的 MVC 框架,然后明年可能就去上海漂啦 😉

扩展业务 | 沈唁志

6 条评论

发表评论

*