phppsr有什么用(PHPpsr)

导读：今天编程笔记来给各位分享关于phppsr有什么用的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 
  1、什么是psr-0，psr-1，psr-2标准
  


• 
  2、PHP的PSR系列规范都有啥内容，phppsr规范有啥
  


• 
  3、PHP 的包管理工具 -- Composer
  


• 
  4、php是如何引入PSR规范
  

什么是psr-0，psr-1，psr-2标准

转自：

FIG组织在制定跟PHP相关规范，简称PSR，PSR旨在通过讨论我们代码项目的共同点以找出一个协作编程的方法。

什么是psr0强调自动加载的方式

下文描述了若要使用一个通用的自动加载器(autoloader)，你所需要遵守的规范：

规范

一个完全标准的命名空间(namespace)和类(class)的结构是这样的：\*

每个命名空间(namespace)都必须有一个顶级的空间名(namespace)("组织名(Vendor Name)")。

每个命名空间(namespace)中可以根据需要使用任意数量的子命名空间(sub-namespace)。

从文件系统中加载源文件时，空间名(namespace)中的分隔符将被转换为 DIRECTORY_SEPARATOR。

类名(class name)中的每个下划线_都将被转换为一个DIRECTORY_SEPARATOR。下划线_在空间名(namespace)中没有什么特殊的意义。

完全标准的命名空间(namespace)和类(class)从文件系统加载源文件时将会加上.php后缀。

组织名(vendor name)，空间名(namespace)，类名(class name)都由大小写字母组合而成。

示例

\Doctrine\Common\IsolatedClassLoader = /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php

\Symfony\Core\Request = /path/to/project/lib/vendor/Symfony/Core/Request.php

\Zend\Acl = /path/to/project/lib/vendor/Zend/Acl.php

\Zend\Mail\Message = /path/to/project/lib/vendor/Zend/Mail/Message.php

空间名(namespace)和类名(class name)中的下划线

\namespace\package\Class_Name = /path/to/project/lib/vendor/namespace/package/Class/Name.php

\namespace\package_name\Class_Name = /path/to/project/lib/vendor/namespace/package_name/Class/Name.php

以上是我们为实现通用的自动加载而制定的最低标准。你可以利用能够自动加载PHP 5.3类的SplClassLoader来测试你的代码是否符合这些标准。

实例

下面是一个怎样利用上述标准来实现自动加载的示例函数。

?php

function autoload($className)

{

$className = ltrim($className, '\\');

$fileName = '';

$namespace = '';

if ($lastNsPos = strrpos($className, '\\')) {

$namespace = substr($className, 0, $lastNsPos);

$className = substr($className, $lastNsPos + 1);

$fileName = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR;

}

$fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';

require $fileName;

}

SplClassLoader实现

下面的gist是一个按照上面建议的标准来自动加载类的SplClassLoader实例。这是依据这些标准来加载PHP 5.3类的推荐方案。

什么是psr1，定义基本代码规范

本节我们将会讨论一些基本的代码规范问题，以此作为将来讨论更高级别的代码分享和技术互用的基础。

RFC 2119中的必须(MUST)，不可(MUST NOT)，建议(SHOULD)，不建议(SHOULD NOT)，可以/可能(MAY)等关键词将在本节用来做一些解释性的描述。

1. 概述

源文件必须只使用 和 这两种标签。

源文件中php代码的编码格式必须只使用不带字节顺序标记(BOM)的UTF-8。

一个源文件建议只用来做声明（类(class)，函数(function)，常量(constant)等）或者只用来做一些引起副作用的操作（例如：输出信息，修改.ini配置等）,但不建议同时做这两件事。

命名空间(namespace)和类(class) 必须遵守PSR-0标准。

类名(class name) 必须使用骆驼式(StudlyCaps)写法 (译者注：驼峰式(cameCase)的一种变种，后文将直接用StudlyCaps表示)。

类(class)中的常量必须只由大写字母和下划线(_)组成。

方法名(method name) 必须使用驼峰式(cameCase)写法(译者注：后文将直接用camelCase表示)。

2. 文件

2.1. PHP标签

PHP代码必须只使用长标签()或者短输出式标签(?= ?)；而不可使用其他标签。

2.2. 字符编码

PHP代码的编码格式必须只使用不带字节顺序标记(BOM)的UTF-8。

2.3. 副作用

一个源文件建议只用来做声明（类(class)，函数(function)，常量(constant)等）或者只用来做一些引起副作用的操作（例如：输出信息，修改.ini配置等）,但不建议同时做这两件事。

短语副作用(side effects)的意思是 在包含文件时 所执行的逻辑与所声明的类(class)，函数(function)，常量(constant)等没有直接的关系。

副作用(side effects)包含但不局限于：产生输出，显式地使用require或include，连接外部服务，修改ini配置，触发错误或异常，修改全局或者静态变量，读取或修改文件等等

下面是一个既包含声明又有副作用的示例文件；即应避免的例子：

?php

// 副作用：修改了ini配置

ini_set('error_reporting', E_ALL);

// 副作用：载入了文件

include "file.php";

// 副作用：产生了输出

echo "html\n";

// 声明

function foo()

{

// 函数体

}

下面是一个仅包含声明的示例文件；即应提倡的例子：

?php

// 声明

function foo()

{

// 函数体

}

// 条件式声明不算做是副作用

if (! function_exists('bar')) {

function bar()

{

// 函数体

}

}

3. 空间名(namespace)和类名(class name)

命名空间(namespace)和类(class)必须遵守 PSR-0.

这意味着一个源文件中只能有一个类(class)，并且每个类(class)至少要有一级空间名（namespace）：即一个顶级的组织名(vendor name)。

类名(class name) 必须使用StudlyCaps写法。

PHP5.3之后的代码必须使用正式的命名空间(namespace) 例子：

?php

// PHP 5.3 及之后:

namespace Vendor\Model;

class Foo

{

}

PHP5.2.x之前的代码建议用伪命名空间Vendor_作为类名(class name)的前缀

?php

// PHP 5.2.x 及之前:

class Vendor_Model_Foo

{

}

4. 类的常量、属性和方法

术语类(class)指所有的类(class)，接口(interface)和特性(trait)

4.1. 常量

类常量必须只由大写字母和下划线(_)组成。 例子：

?php

namespace Vendor\Model;

class Foo

{

const VERSION = '1.0';

const DATE_APPROVED = '2012-06-01';

}

4.2. 属性

本指南中故意不对$StulyCaps，$camelCase或者$unser_score中的某一种风格作特别推荐，完全由读者依据个人喜好决定属性名的命名风格。

但是不管你如何定义属性名，建议在一个合理的范围内保持一致。这个范围可能是组织(vendor)级别的，包(package)级别的，类(class)级别的，或者方法(method)级别的。

4.3. 方法

方法名则必须使用camelCase()风格来声明。

什么是PSR2定义代码风格

代码风格指南

本手册是基础代码规范(PSR-1)的继承和扩展。

为了尽可能的提升阅读其他人代码时的效率，下面例举了一系列的通用规则，特别是有关于PHP代码风格的。

各个成员项目间的共性组成了这组代码规范。当开发者们在多个项目中合作时，本指南将会成为所有这些项目中共用的一组代码规范。 因此，本指南的益处不在于这些规则本身，而在于在所有项目中共用这些规则。

RFC 2119中的必须(MUST)，不可(MUST NOT)，建议(SHOULD)，不建议(SHOULD NOT)，可以/可能(MAY)等关键词将在本节用来做一些解释性的描述。

PHP的PSR系列规范都有啥内容，phppsr规范有啥

就是个死规范，个人感觉那些规范实在是太规范了，什么还不能用tab的，还得空格按两下才行，谁开发要那么麻烦，我干三年了都没用过那么麻烦的，thinkphp自带的函数库也没那规范

PHP 的包管理工具 -- Composer

Composer 是 PHP 的一个包管理和包依赖管理的工具 ( 官方的定义是 "Dependency Manager for PHP" ), 类似 Mac 的 Homebrew , CentOS 的 yum , Windows 的 Chocolatey , 以及 Node.js 的 npm 和 Python 的 pip .

在 Composer 出现之前使用 PHP 第三方包的操作:

这种方式带来的问题:

Composer 要求 PHP 5.3.2 以上 (官方推荐使用 5.3.4 以上, 以避免潜在的问题).

如果在安装时提醒缺少组件, 跟着提示解决即可.

由于众所周知的原因, 访问 Composer 官方的 packagist 网站速度比较慢, 可以选用第三方在国内做的全景镜像, 提高速度:

以使用 markdown 为例:

有些包并不是提供一个特定功能的类库, 而是提供一个完整的框架, 比如说 Laravel 和 yii2.

直接创建项目的 Composer 命令是:

所以用 Composer 直接创建一个 Laravel 或者 yii2 的项目的命令是:

该命令主要有 2 个作用:

比如:

公司开始规范开发, 逐步引入 PSR, Laravel 框架, PHPUnit, Composer...

从个人来说, 真的很幸运, 能够在这么一个时期加入公司, 在顺流中借势成长. 这也是为什么写这篇博客的原因 -- 当然, 这也是一个博客系列的开始

php是如何引入PSR规范

PSR规范只是一套规范，你可以按规范来编码也可以不按规范来编码。

如果说是“引入”这个词的话，那只有IDE的PSR规范检查功能称的上所谓的“引入”。你用的IDE打开PSR规范检查后，你敲代码的时候会自动对你的代码是否符合规范进行检查。

每个IDE不同，有些已经集成了，只需要打开。有些则需要装扩展。

结语：以上就是编程笔记为大家整理的关于phppsr有什么用的全部内容了，感谢您花时间阅读本站内容，希望对您有所帮助，更多关于phppsr有什么用的相关内容别忘了在本站进行查找喔。