长篇慎入

分以下几点说明

  • 一些编码的经验
  • PSR-1
  • PSR-2
  • PSR-3
  • PSR-4

一些编码的经验

变量命名

  1. 不用拼音
  2. 驼峰或下划线风格要一致
  3. 单词要有意义
  4. 不用关键字
  5. 常量全大写用下划线连接

代码注释

  1. 尽量让代码可读性提高,减少代码上的注释
  2. 函数头部可以描述参数和返回值及功能的注释
  3. 算法类代码一定要加注释说明

代码备份

使用 github, 本地留一份

编码统一

PHP编码 == HTML编码 == 数据库编码 == UTF-8

header("Content-type: text/html; charset=utf-8");

路径常量

所有路径和URL尽量使用常量进行存放

不写结束标记 ?>

<?php

//code

错误记录

  • 开发环境开启错误调试
error_reporting(7);
ini_set('display_errors', true);

E_ERROR

E_WARNING

E_NOTICE

  • 生产环境写入日志中

  • 千万别用 @ 符号屏蔽错误

变量使用

  1. 使用前进行初始化

不规范

array_push($arr, 'test');

规范

$arr = [];
array_push($arr, 'test');
  1. 键值要用引号围起来

不规范

echo $_GET[name];

规范

echo $_GET['name'];
  1. 等式判断尽量用全等
echo $number === 1;
  1. 循环内尽量少放表达式

不规范

for ($i=0; $i<strlen($data); $i++){
// code
}

规范

$len = strlen($data);
for ($i=0; $i<$len $i++){
// code
}

函数使用

  1. strtr 比 str_replace 快四倍

  2. 使用 microtime 检测执行时间

  3. 返回值: 操作类函数返回ture/false, 数据类函数返回data/null

  4. 尽量使用内置函数,少用正则

filter_var('test@qq.com', FILTER_VALIDATE_EMAIL);
parse_url        解析URL返回各个成分
http_build_query 生成 urlencode 后的请求字符串
exif_imagetype 判断图像类型
uniqid 生成唯一ID
get_browser 获取浏览器信息

对所有外部输入变量进行校验

用户输入,函数传值时, 应该考虑到:

  1. 为空的情况

  2. 畸形数据如SQL注入

  3. 溢出或变量类型不一致

  4. 不要相信数据的可靠性

对于SQL注入,可以使用 PDO

对于XSS攻击,htmlspecialchars 只能防御一小部分

  1. 小心使用可执行命令: eval system 等

语法糖

下面这些均不时函数,算是内置的指令

echo()
print()
die()
exit()
unset()
isset()
include()
include_once()
require()
require_once()
array()
list()
empty()
eval()

其他的一些语法糖, 均下一行写法比上一行写法好点

echo $a . $b;
echo $a , $b;
echo strlen($str) === 5;
echo isset($str[4])
$arr = array();
$arr = [];
function sum($a, $b, $c, $d, $e){
return $a + $b + $c + $d + $e;
} function sum(...$n){
return array_sum($n);
}

eval 的防御

php.ini 的 disbale_function 只能禁用函数,但eval不属于函数

使用 suhosin 来防御

php.ini

suhosin.executor.disable_eval = on

代码简化

if else 简化

if (1 == $orderState)
$status = 'success';
else
$status = 'error'; return $status;
$status = 'error';

if ( 1== $orderState)
$status = 'success'; return $status;

空值赋予默认简化

if (!empty($_POST['action']))
$action = $_POST['action'];
else
$action = 'default';
$action = $_POST['action'] ?? 'default';

中间值提高可读性

return implode('', array_map('ucfirst', explode('_', 'this_is_test')));
$str = 'this_is_test';
$words = explode('_', $str);
$uWords = array_map('ucfirst', $words);
$res = implode('', $uWords);

代码长度

函数长度保持 50-150行内

函数参数长度 不超过7个

函数只做一件事情,易于复用

标准规范

PSR

关键词:

  • 必须 (must)
  • 不能 (must not)
  • 需要 (required)
  • 将会 (shall)
  • 不会 (shall not)
  • 应该 (should)
  • 不该 (should not)
  • 推荐 (recommended)
  • 可以 (may)
  • 可选 (optional)

详情参见 RFC2119

PSR-0(废弃)

PSR-1

  • PHP标签

PHP代码必须使用 <?php ?> 长标签 或 <?= ?> 短输出标签; 一定不可使用其它自定义标签。

  • 字符编码

PHP代码必须且只可使用不带BOMUTF-8编码

  • 从属效应

一份PHP文件中应该要不就只定义新的声明,如类、函数或常量等不产生从属效应的操作,要不就只有会产生从属效应的逻辑操作,但不该同时具有两者。

从属效应(side effects)意思是: 仅仅通过包含文件,不直接声明类、 函数和常量等,而执行的逻辑操作。

从属效应包含却不仅限于:

  1. 生成输出
  2. 直接的 require 或 include
  3. 连接外部服务
  4. 修改 ini 配置
  5. 抛出错误或异常
  6. 修改全局或静态变量
  7. 读或写文件

    ...

以下是一个错误的例子,一份包含声明以及产生从属效应的代码:

<?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()
{
// 函数主体部分
}
}
  • 命名空间和类

命名空间以及类的命名必须遵循 PSR-4

根据规范,每个类都独立为一个文件,且命名空间至少有一个层次:顶级的组织名称(vendor name)。

类的命名必须 遵循 StudlyCaps 大写开头的驼峰命名规范。

PHP 5.3及以后版本的代码必须使用正式的命名空间。

例如:

<?php
// PHP 5.3及以后版本的写法
namespace Vendor\Model; class Foo
{
}

5.2.x及之前的版本应该使用伪命名空间的写法,约定俗成使用顶级的组织名称(vendor name)如 Vendor_ 为类前缀。

<?php
// 5.2.x及之前版本的写法
class Vendor_Model_Foo
{
}

类的常量、属性和方法

此处的“类”指代所有的类、接口以及可复用代码块(traits)

  • 常量

类的常量中所有字母都必须大写,词间以下划线分隔。 参照以下代码:

<?php
namespace Vendor\Model; class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
}
  • 方法

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

  • 属性

类的属性命名可以遵循:

  1. 大写开头的驼峰式 ($StudlyCaps)
  2. 小写开头的驼峰式 ($camelCase)
  3. 下划线分隔式 ($under_score),

本规范不做强制要求,但无论遵循哪种命名方式,都应该在一定的范围内保持一致

这个范围可以是整个团队、整个包、整个类或整个方法。

PSR-2

本篇规范是 PSR-1 基本代码规范的继承与扩展。

本规范希望通过制定一系列规范化PHP代码的规则,以减少在浏览不同作者的代码时,因代码风格的不同而造成不便。

当多名程序员在多个项目中合作时,就需要一个共同的编码规范, 而本文中的风格规范源自于多个不同项目代码风格的共同特性, 因此,本规范的价值在于我们都遵循这个编码风格,而不是在于它本身。

符合规范的小例子

<?php
namespace Vendor\Package; use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass; class Foo extends Bar implements FooInterface
{
public function sampleFunction($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClass::bar($arg2, $arg3);
}
} final public static function bar()
{
// method body
}
}
  • 编码基准

必须遵守 PSR-1

  • 文件

所有PHP文件必须使用Unix LF (linefeed)作为行的结束符。

所有PHP文件必须以一个空白行作为结束。

纯PHP代码文件必须省略最后的 ?> 结束标签。

行的长度一定不能有硬性的约束。

软性的长度约束一定要限制在120个字符以内,若超过此长度,带代码规范检查的编辑器一定要发出警告,不过一定不可发出错误提示。

每行不应该多于80个字符,大于80字符的行应该折成多行。

非空行后一定不能有多余的空格符。

空行可以使得阅读代码更加方便以及有助于代码的分块。

每行一定不能存在多于一条语句。

  • 缩进

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

备注: 使用空格而不是tab键缩进的好处在于, 避免在比较代码差异、打补丁、重阅代码以及注释时产生混淆。 并且,使用空格缩进,让对齐变得更方便。
  • 关键字

PHP所有 关键字必须全部小写。

常量 true false null 也必须全部小写。

  • namespace 以及 use 声明

namespace 声明后必须插入一个空白行。

所有 use 必须在 namespace 后。

每条 use 声明语句必须只有一个 use 关键词。

use 声明语句块后必须要有一个空白行。

<?php
namespace Vendor\Package; use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass; // ... additional PHP code ...
  • 扩展与继承

关键词 extendsimplements 必须写在类名称的同一行

<?php
namespace Vendor\Package; use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass; class ClassName extends ParentClass implements \ArrayAccess, \Countable
{
// constants, properties, methods
}

implements 的继承列表也可以分成多行,这样的话,每个继承接口名称都必须分开独立成行,包括第一个。

<?php
namespace Vendor\Package; use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass; class ClassName extends ParentClass implements
\ArrayAccess,
\Countable,
\Serializable
{
// constants, properties, methods
}
  • 属性

每个属性都必须添加访问修饰符。

一定不可使用关键字 var 声明一个属性。

每条语句一定不可定义超过一个属性。

不要使用下划线作为前缀,来区分属性是 protected 或 private。

以下是属性声明的一个范例:

<?php
namespace Vendor\Package; class ClassName
{
public $foo = null;
}
  • 方法

所有方法都必须添加访问修饰符。

不要使用下划线作为前缀,来区分方法是 protected 或 private。

方法名称后一定不能有空格符,其开始花括号必须独占一行,结束花括号也必须在方法主体后单独成一行。参数左括号后和右括号前一定不能有空格。

一个标准的方法声明可参照以下范例,留意其括号、逗号、空格以及花括号的位置。

<?php
namespace Vendor\Package; class ClassName
{
public function fooBarBaz($arg1, &$arg2, $arg3 = [])
{
// method body
}
}
  • 方法的参数

参数列表中,每个逗号后面必须要有一个空格,而逗号前面一定不能有空格。

有默认值的参数,必须放到参数列表的末尾。

<?php
namespace Vendor\Package; class ClassName
{
public function foo($arg1, &$arg2, $arg3 = [])
{
// method body
}
}

参数列表可以分列成多行,这样,包括第一个参数在内的每个参数都必须单独成行。

拆分成多行的参数列表后,结束括号以及方法开始花括号 必须 写在同一行,中间用一个空格分隔。

<?php
namespace Vendor\Package; class ClassName
{
public function aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = []
) {
// method body
}
}
  • abstract 、 final 、 以及 static

需要添加 abstract 或 final 声明时, 必须写在访问修饰符前,而 static 则必须写在其后。

<?php
namespace Vendor\Package; abstract class ClassName
{
protected static $foo; abstract protected function zim(); final public static function bar()
{
// method body
}
}

4.6. 方法及函数调用

方法及函数调用时,方法名或函数名与参数左括号之间一定不能有空格,参数右括号前也 一定不能有空格。每个逗号前一定不能有空格,但其后必须有一个空格。

<?php
bar();
$foo->bar($arg1);
Foo::bar($arg2, $arg3);

参数可以分列成多行,此时包括第一个参数在内的每个参数都必须单独成行。

<?php
$foo->bar(
$longArgument,
$longerArgument,
$muchLongerArgument
);
  • 控制结构

    控制结构的基本规范如下:

控制结构关键词后必须有一个空格。

左括号 ( 后一定不能有空格。

右括号 ) 前也一定不能有空格。

右括号 ) 与开始花括号 { 间一定有一个空格。

结构体主体一定要有一次缩进。

结束花括号 } 一定在结构体主体后单独成行。

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

  • if 、 elseif 和 else

标准的 if 结构如下代码所示,留意 括号、空格以及花括号的位置, 注意 else 和 elseif 都与前面的结束花括号在同一行。

<?php
if ($expr1) {
// if body
} elseif ($expr2) {
// elseif body
} else {
// else body;
}

应该使用关键词 elseif 代替所有 else if ,以使得所有的控制关键字都像是单独的一个词。

  • switch 和 case

标准的 switch 结构如下代码所示,留意括号、空格以及花括号的位置。

case 语句必须相对 switch 进行一次缩进,

而 break 语句以及 case 内的其它语句都 必须 相对 case 进行一次缩进。

如果存在非空的 case 直穿语句,主体里必须有类似 // no break 的注释。

<?php
switch ($expr) {
case 0:
echo 'First case, with a break';
break;
case 1:
echo 'Second case, which falls through';
// no break
case 2:
case 3:
case 4:
echo 'Third case, return instead of break';
return;
default:
echo 'Default case';
break;
}
  • while 和 do while

    一个规范的 while 语句应该如下所示,注意其 括号、空格以及花括号的位置。
<?php
while ($expr) {
// structure body
}

标准的 do while 语句如下所示,同样的,注意其 括号、空格以及花括号的位置。

<?php
do {
// structure body;
} while ($expr);
  • for

    标准的 for 语句如下所示,注意其 括号、空格以及花括号的位置。
<?php
for ($i = 0; $i < 10; $i++) {
// for body
}
  • foreach

    标准的 foreach 语句如下所示,注意其 括号、空格以及花括号的位置。
<?php
foreach ($iterable as $key => $value) {
// foreach body
}
  • try, catch

    标准的 try catch 语句如下所示,注意其 括号、空格以及花括号的位置。
<?php
try {
// try body
} catch (FirstExceptionType $e) {
// catch body
} catch (OtherExceptionType $e) {
// catch body
}
  • 闭包

闭包声明时,关键词 function 后以及关键词 use 的前后都必须要有一个空格。

开始花括号必须写在声明的同一行,结束花括号必须紧跟主体结束的下一行。

参数列表和变量列表的左括号后以及右括号前,必须不能有空格。

参数和变量列表中,逗号前必须不能有空格,而逗号后必须要有空格。

闭包中有默认值的参数必须放到列表的后面。

标准的闭包声明语句如下所示,注意其 括号、逗号、空格以及花括号的位置。

<?php
$closureWithArgs = function ($arg1, $arg2) {
// body
}; $closureWithArgsAndVars = function ($arg1, $arg2) use ($var1, $var2) {
// body
};

参数列表以及变量列表可以分成多行,这样,包括第一个在内的每个参数或变量都必须单独成行,而列表的右括号与闭包的开始花括号必须放在同一行。

以下几个例子,包含了参数和变量列表被分成多行的多情况。

<?php
$longArgs_noVars = function (
$longArgument,
$longerArgument,
$muchLongerArgument
) {
// body
}; $noArgs_longVars = function () use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
}; $longArgs_longVars = function (
$longArgument,
$longerArgument,
$muchLongerArgument
) use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
}; $longArgs_shortVars = function (
$longArgument,
$longerArgument,
$muchLongerArgument
) use ($var1) {
// body
}; $shortArgs_longVars = function ($arg) use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
};

注意,闭包被直接用作函数或方法调用的参数时,以上规则仍然适用。

<?php
$foo->bar(
$arg1,
function ($arg2) use ($var1) {
// body
},
$arg3
);
  • 多行参数 (09/08/2013)

使用一个或多个跨行的参数(如数组和匿名函数)并不需要触发 4.6 节中关于参数列表的单行规定, 因此,在参数表中的数组和匿名函数是可以单独分列成多行的。

以下的例子是符合 PSR-2 规范的:

<?php
somefunction($foo, $bar, [
// ...
], $baz); $app->get('/hello/{name}', function ($name) use ($app) {
return 'Hello '.$app->escape($name);
  • 总结

    以上规范难免有疏忽,其中包括但不仅限于:

全局变量和常量的定义

函数的定义

操作符和赋值

行内对齐

注释和文档描述块

类名的前缀及后缀

最佳实践

本规范之后的修订与扩展将弥补以上不足。

PSR-3

日志接口规范

本文制定了日志类库的通用接口规范。

本规范的主要目的,是为了让日志类库以简单通用的方式,

通过接收一个 Psr\Log\LoggerInterface 对象,来记录日志信息。

框架以及CMS内容管理系统如有需要,可以对此接口进行扩展,

但需遵循本规范,这才能保证在使用第三方的类库文件时,日志接口仍能正常对接。

  1. 基本规范
  • LoggerInterface 接口对外定义了八个方法,分别用来记录 RFC 5424 中定义的八个等级的日志:
  1. debug
  2. info
  3. notice
  4. warning
  5. error
  6. critical
  7. alert
  8. emergency
  • 第九个方法 —— log,其第一个参数为记录的等级。可使用一个预先定义的等级常量作为参数来调用此方法,必须与直接调用以上八个方法具有相同的效果。

如果传入的等级常量参数没有预先定义,则必须抛出 Psr\Log\InvalidArgumentException 类型的异常。

在不确定的情况下,使用者不该使用未支持的等级常量来调用此方法。

1.2 记录信息

  • 以上每个方法都接受一个字符串类型或者是有 __toString() 方法的对象作为记录信息参数,这样,实现者就能把它当成字符串来处理,否则实现者必须自己把它转换成字符串。

  • 记录信息参数可以携带占位符,实现者可以根据上下文将其它替换成相应的值。

    其中占位符必须与上下文数组中的键名保持一致。

    占位符的名称必须由一个左花括号 { 以及一个右括号 } 包含。但花括号与名称之间一定不能有空格符。

    占位符的名称应该只由 A-Za-z,0-9、下划线 _、以及英文的句号 .组成,其它字符作为将来占位符规范的保留。

    实现者可以通过对占位符采用不同的转义和转换策略,来生成最终的日志。

    而使用者在不知道上下文的前提下,不该提前转义占位符。

    以下是一个占位符使用的例子:

    /**
    * 用上下文信息替换记录信息中的占位符
    */
    function interpolate($message, array $context = array())
    {
    // 构建一个花括号包含的键名的替换数组
    $replace = array();
    foreach ($context as $key => $val) {
    $replace['{' . $key . '}'] = $val;
    } // 替换记录信息中的占位符,最后返回修改后的记录信息。
    return strtr($message, $replace);
    } // 含有带花括号占位符的记录信息。
    $message = "User {username} created"; // 带有替换信息的上下文数组,键名为占位符名称,键值为替换值。
    $context = array('username' => 'bolivar'); // 输出 "Username bolivar created"
    echo interpolate($message, $context);

1.3 上下文

  • 每个记录函数都接受一个上下文数组参数,用来装载字符串类型无法表示的信息。它可以装载任何信息,所以实现者必须确保能正确处理其装载的信息,对于其装载的数据,一定不能 抛出异常,或产生PHP出错、警告或提醒信息(error、warning、notice)。

  • 如需通过上下文参数传入了一个 Exception 对象, 必须'exception' 作为键名。

    记录异常信息是很普遍的,所以如果它能够在记录类库的底层实现,就能够让实现者从异常信息中抽丝剥茧。

    当然,实现者在使用它时,必须确保键名为 'exception' 的键值是否真的是一个 Exception,毕竟它可以装载任何信息。

1.4 助手类和接口

  • Psr\Log\AbstractLogger 类使得只需继承它和实现其中的 log 方法,就能够很轻易地实现 LoggerInterface 接口,而另外八个方法就能够把记录信息和上下文信息传给它。

  • 同样地,使用 Psr\Log\LoggerTrait 也只需实现其中的 log 方法。不过,需要特别注意的是,在traits可复用代码块还不能实现接口前,还需要 implement LoggerInterface

  • 在没有可用的日志记录器时, Psr\Log\NullLogger 接口可以为使用者提供一个备用的日志“黑洞”。不过,当上下文的构建非常消耗资源时,带条件检查的日志记录或许是更好的办法。

  • Psr\Log\LoggerAwareInterface 接口仅包括一个

    setLogger(LoggerInterface $logger) 方法,框架可以使用它实现自动连接任意的日志记录实例。

  • Psr\Log\LoggerAwareTrait trait可复用代码块可以在任何的类里面使用,只需通过它提供的 $this->logger,就可以轻松地实现等同的接口。

  • Psr\Log\LogLevel 类装载了八个记录等级常量。


上述的接口、类和相关的异常类,以及一系列的实现检测文件,都包含在 psr/log 文件包中。

  1. Psr\Log\LoggerInterface

<?php

namespace Psr\Log;

/**
* 日志记录实例
*
* 日志信息变量 —— message, **必须**是一个字符串或是实现了 __toString() 方法的对象。
*
* 日志信息变量中**可以**包含格式如 “{foo}” (代表foo) 的占位符,
* 它将会由上下文数组中键名为 "foo" 的键值替代。
*
* 上下文数组可以携带任意的数据,唯一的限制是,当它携带的是一个 exception 对象时,它的键名 必须 是 "exception"。
*
* 详情可参阅: https://github.com/PizzaLiu/PHP-FIG/blob/master/PSR-3-logger-interface-cn.md
*/
interface LoggerInterface
{
/**
* 系统不可用
*
* @param string $message
* @param array $context
* @return null
*/
public function emergency($message, array $context = array()); /**
* **必须**立刻采取行动
*
* 例如:在整个网站都垮掉了、数据库不可用了或者其他的情况下,**应该**发送一条警报短信把你叫醒。
*
* @param string $message
* @param array $context
* @return null
*/
public function alert($message, array $context = array()); /**
* 紧急情况
*
* 例如:程序组件不可用或者出现非预期的异常。
*
* @param string $message
* @param array $context
* @return null
*/
public function critical($message, array $context = array()); /**
* 运行时出现的错误,不需要立刻采取行动,但必须记录下来以备检测。
*
* @param string $message
* @param array $context
* @return null
*/
public function error($message, array $context = array()); /**
* 出现非错误性的异常。
*
* 例如:使用了被弃用的API、错误地使用了API或者非预想的不必要错误。
*
* @param string $message
* @param array $context
* @return null
*/
public function warning($message, array $context = array()); /**
* 一般性重要的事件。
*
* @param string $message
* @param array $context
* @return null
*/
public function notice($message, array $context = array()); /**
* 重要事件
*
* 例如:用户登录和SQL记录。
*
* @param string $message
* @param array $context
* @return null
*/
public function info($message, array $context = array()); /**
* debug 详情
*
* @param string $message
* @param array $context
* @return null
*/
public function debug($message, array $context = array()); /**
* 任意等级的日志记录
*
* @param mixed $level
* @param string $message
* @param array $context
* @return null
*/
public function log($level, $message, array $context = array());
}
  1. Psr\Log\LoggerAwareInterface

<?php

namespace Psr\Log;

/**
* logger-aware 定义实例
*/
interface LoggerAwareInterface
{
/**
* 设置一个日志记录实例
*
* @param LoggerInterface $logger
* @return null
*/
public function setLogger(LoggerInterface $logger);
}
  1. Psr\Log\LogLevel

<?php

namespace Psr\Log;

/**
* 日志等级常量定义
*/
class LogLevel
{
const EMERGENCY = 'emergency';
const ALERT = 'alert';
const CRITICAL = 'critical';
const ERROR = 'error';
const WARNING = 'warning';
const NOTICE = 'notice';
const INFO = 'info';
const DEBUG = 'debug';
}

PSR-4

自动加载(Autoloader)

本 PSR 是关于由文件路径 自动载入 对应类的相关规范,

本规范是可互操作的,可以作为任一自动载入规范的补充,

其中包括 PSR-0,此外, 本 PSR 还包括自动载入的类对应的文件存放路径规范。

  • 详细说明
  1. 此处的“类”泛指所有的class类、接口、traits可复用代码块以及其它类似结构。

  2. 一个完整的类名需具有以下结构:

     \<命名空间>(\<子命名空间>)*\<类名>
    1. 完整的类名必须要有一个顶级命名空间,被称为 "vendor namespace";

    2. 完整的类名可以有一个或多个子命名空间;

    3. 完整的类名必须有一个最终的类名;

    4. 完整的类名中任意一部分中的下划线都是没有特殊含义的;

    5. 完整的类名可以由任意大小写字母组成;

    6. 所有类名都必须是大小写敏感的。

  3. 当根据完整的类名载入相应的文件……

    1. 完整的类名中,去掉最前面的命名空间分隔符,前面连续的一个或多个命名空间和子命名空间,作为“命名空间前缀”,其必须与至少一个“文件基目录”相对应;

    2. 紧接命名空间前缀后的子命名空间必须与相应的”文件基目录“相匹配,其中的命名空间分隔符将作为目录分隔符。

    3. 末尾的类名必须与对应的以 .php 为后缀的文件同名。

    4. 自动加载器(autoloader)的实现一定不能抛出异常、一定不能触发任一级别的错误信息以及不应该有返回值。

  • 例子

下表展示了符合规范完整类名、命名空间前缀和文件基目录所对应的文件路径。

\Acme\Log\Writer\File_WriterAcme\Log\Writer./acme-log-writer/lib/./acme-log-writer/lib/File_Writer.php
\Aura\Web\Response\StatusAura\Web/path/to/aura-web/src//path/to/aura-web/src/Response/Status.php
\Symfony\Core\RequestSymfony\Core./vendor/Symfony/Core/./vendor/Symfony/Core/Request.php
\Zend\AclZend/usr/includes/Zend//usr/includes/Zend/Acl.php

关于本规范的实现,可参阅 相关实例

注意:实例并属于规范的一部分,且随时有所变动。

05-27 11:11