php中类文件的命名规则_PHP编码规范（中文版）

PSR-4 标准补充 1.概述

本文的目的是为 PHP 加载器的命名空间映射文件系统路径建立一个统一的规则，并自动附加到其他 SPL 注册中

运营商共存。本文旨在作为补充，而不是取代 PSR-0。

2. 你为什么要这样做？前 PSR-0

PSR-0 类命名和自动加载标准基于 PHP 5.2 和广泛接受的 Horde/REAR 约定

习惯上将所有 PHP 类源代码放在一个主目录中，并在类名中使用下划线来表示伪命名空间，如下所示：

/path/to/src/
    VendorFoo/
        Bar/
            Baz.php     # VendorFoo_Bar_Baz
    VendorDib/
        Zim/
            Gir.php     # Vendor_Dib_Zim_Gir

随着 PHP 5.3 的发布，可以使用适当的命名空间语法，并且引入了 PSR-0 以允许使用旧式的 Horde/PEAR 下划线

架构并使用新的命名空间表示法。为了便于从旧式命名到新式命名的过渡，类名中仍允许使用下划线

，这允许更广泛的使用。

/path/to/src/
    VendorFoo/
        Bar/
            Baz.php     # VendorFoo_Bar_Baz
    VendorDib/
        Zim/
            Gir.php     # VendorDib_Zim_Gir
    Irk_Operation/
        Impending_Doom/
            V1.php
            V2.php      # Irk_Operation\Impending_Doom\V2

在使用 PEAR 安装程序将源文件从 PEAR 包移动到单个中央目录的情况下，这种结构非常合理。

到来

包源不会复制到单个全局位置，而是在安装位置使用，不会来回移动。这意味着，没有

PEAR 作为 PHP 源代码的“单一主目录”。相反，有多个目录，每个包都位于每个项目的单独目录中

中间。

为了满足 PSR-0 的要求，这导致包看起来像这样：

vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

“src” 和 “tests” 目录必须包含 和 包目录名称，这些名称是 PSR-0 合规性的产物。

许多人发现这种结构比必要的更深、更重复。该提案表明，补充或取代 PSR 将比我们的 PSR 更有用

确实如此

该包如下所示：

vendor/
    vendor_name/
        package_name/
            src/
                ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

这将需要实现最初称为“面向包”的自动加载（而不是传统的“简单的类到文件自动加载”）。

定向 - 自动装载包裹

它

通过扩展或修改 PSR-0 来实现 - 的自动加载非常困难，因为 PSR-0 不允许在类名路径之间进行任何修改

部分。这意味着实现面向数据包的自动加载比 PSR-0 复杂得多，但是，它将使包更干净。

最初，建议遵循以下规则：

实现者必须使用两个以上的命名空间层次结构：一个名称和一个包名称。（这两个顶部

.）

名称组合缩写为 - 或 -。

实现者必须允许 - 完全限定类名的其余部分之间的路径后缀。

- 可以映射到任何目录。若要完全限定类名的其余部分，必须映射命名空间名称

对于具有相同名称的目录，必须将类名映射到以 .php 结尾的同名文件。

请注意，这意味着停止在类名中添加下划线作为目录分隔符的做法。有人可能会认为下划线应该在出现时遵循

在 PSR-0 规范中，但在文档中它们被用作 PHP 5.2 或更早版本的伪命名空间转换，因此

最好在这里删除它们。

3. 范围 3.1 目标 3.2 非目标 4.选项 4.1 最佳方案

该解决方案保留了 PSR-0 的关键功能，同时消除了更深层次的目录结构。此外，还指定了一些附加规则以使其更清晰

互操作性实现。

虽然它不涉及目录映射，但最终草案指定了自动加载程序应如何处理错误。具体来说，它禁止抛出异常或提及

这有两个原因。

PHP 中的自动加载器设计是可堆叠的，如果一个自动加载器没有加载，其他自动加载器仍然有机会继续加载。㞖

其中一个自动加载器发生错误，该过程将无法继续。

（） 和 （） 允许在正常自动加载后找到类或接口，如果

移动加载程序会引发异常，使 （） 不可用，从互操作性的角度来看，这是不可接受的。自动加载

如果找不到该类，最好通过日志记录提供额外的调试信息，可以是符合 PSR-3 的日志记录或其他

什么。

优点：

缺点：

4.2 替代方案：仍遵循 PSR-0 标准

仍然遵循 PSR-0 标准，虽然合理，但只留下了更深层次的目录结构。

优点：

缺点：

4.3 替代方案：自动加载和转换分离

Beau 和其他人建议，可以将转换逻辑与自动加载提案分离，以便其他提案可以引用转换规则。

它们的分离将在未来通过投票和讨论来完成，合并版本（例如，嵌入自动加载提案的转换规则）优先

使用。

优点：

缺点：

4.4 替代方案：使用更多的祈使句和叙述性语言

在第二轮投票之后，发起人最常听到的投票是那些支持该想法但不同意该提案的措辞（或解释）的人，该提案已经提出了一段时间

投票扩大到更多的叙述和一些更命令性的语言，这种做法受到少数直言不讳的参与者的谴责。在那之后的一段时间

Beau 开始专注于对 PSR-0 的实验性修订，编辑和发起人更喜欢这种简洁的方法，并继续将其用于当前的审查

（由贡献最大的贡献者 Paul M. Jones 撰写）。

PHP 5.3.3 及更早版本

在 PHP 5.3.3 之前，前缀命名空间没有被删除，因此特定实例落在特定声明上。省略命名的前缀

空间可能会导致发生异常。

5. 人员5.1 编辑5.2 发起人5.3 贡献者6.投票7.相关链接