在 Nettuts+ 的上一课中,您了解了 PSR;但是,该文章没有详细说明将该编码风格集成到项目中的过程。让我们解决这个问题!
注意:本文假设您已阅读 PSR-Huh?,并了解 PSR 指的是什么。让我们从第一个标准开始:PSR-0。
PHPCS 插件是我用过的最有用的工具。
过去,我们通过以下两种方式之一包含 PHP 文件:
这两种方法各有利弊,但是,我认为我们都同意这两种方法都不是最佳或现代的解决方案。 PHP5引入了根据类名自动加载文件的概念;因此,PSR-0 旨在保持文件名一致。
命名空间与文件名或自动加载无关;从技术上讲,您可以在同一文件中声明不同的名称空间。例如,下面的代码是完全有效的。
<?php namespace Nettuts; Class Hello { public function __construct() { echo "Nettuts+"; } } namespace Gabriel; Class Hello { public function __construct() { echo "Gabriel"; } } $h = new \Nettuts\Hello(); $h = new \Gabriel\Hello();
这个文件中有两个 Hello
类,但它们驻留在不同的命名空间中。此代码的最后两行在各自的命名空间上实例化 Hello()
类。第一个输出“Nettuts+”,而第二个输出“Gabriel”。命名空间允许您区分具有相同名称的两个类,就像您可能习惯于桌面上的文件夹一样。 PSR-0 标准简单地利用了命名空间的优势,使自动加载类变得容易。通过一致地命名文件,您可以创建一个自动查找必要文件的函数。
要符合 PSR-1 标准,您还必须遵循 PSR-0。
请务必阅读完整的标准,但总结一下:
.php
扩展名。例如,类引用:
\Nettuts\Database\SQL_Postgres
如果遵循 PSR-0,应转换为此路径:
./Nettuts/Database/SQL/Postgres.php
我们如何实现此功能?最明显的解决方案是使用 Composer,它附带了符合 PSR-0 标准的自动加载器。如果您在项目中使用 Composer(您应该这样做),那么请选择它的自动加载器,而不是编写自己的自动加载器。
符合 PSR-0 的加载程序允许您指定基本路径,通知加载程序首先查看哪个目录。首先,创建一个简单的 composer.json
文件,其中包含以下 JSON:
{ "autoload": { "psr-0": { "Nettuts": "./", "Gmanricks": "vendor/" } } }
这个 JSON 文件告诉 Composer 我们要使用 PSR-0 标准自动加载所有以当前目录(根文件夹)为基本路径的 Nettuts
命名空间文件。我们还希望使用 Gmanricks
命名空间自动加载相对于 vendor
文件夹的所有类(例如 ./vendor/Gmanricks/ClassName
)。
现在,输入“composer install
”以生成自动加载类,或在后续编辑中输入“composer dump-autoload
”以重新生成自动加载类。另外,不要忘记在项目早期的某个地方需要自动加载器。
<?php require 'vendor/autoload.php';
Composer 是您的最佳选择,但在某些情况下您可能需要一个小型、简单的自动加载器。 PHP-FIG 提供了一个可供您使用的示例自动加载器:
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; }
需要注意的是,此加载器尝试加载当前目录中使用 PSR 标准的所有类。
现在我们已经成功地自动加载类了,让我们继续讨论下一个标准:基本编码标准。
PSR-1 定义了通用编码指南,可以分为两部分。
命名空间允许您区分具有相同名称的两个类。
与任何编程语言一样,遵循命名约定最终会使您的代码更易于阅读和维护。以下是一些需要遵循的规则:
CONSTANT_VARIABLE
)。它不仅仅是命名约定;还请遵循以下准则:
<?php
或 =
。不要在类中关闭 PHP。
其中大部分都是不言自明的,但中间的约定有点令人困惑。它本质上规定任何声明,无论是函数、类等,都应该分离到它们自己的文件中。这不仅促进了代码重用和分离等最佳实践,而且使您的代码保持整洁。
值得一提的是,每个 PSR 标准都建立在之前的 PSR 标准之上。因此,要符合 PSR-1,您还必须遵循 PSR-0。通过遵循这两个标准,您的代码将被正确命名并自动加载。确实没有理由不关注他们。
是的,一些开发人员抱怨 PSR 并更喜欢遵循其他约定,但通过遵循此标准,您可以与所有人共享代码,而不必担心其一致性。话虽如此,没有人强迫你这么做。这只是一个推荐指南。
下一个标准 PSR-2 深入探讨了如何构建代码的细节。
PSR-2 深入探讨了如何构建代码的细节。
接下来,我们来看看 PHP 开发人员最难解决的一个标准:事实上,这就是我选择写这篇文章的原因。
PSR-2 定义了许多规则,其中许多规则如下:
namespace
和 use
声明下应有一个空行。abstract
”/“final
”关键字应出现在可见性之前,而“static
”则出现在可见性之后。请务必查看整个规范以获得完整的概述。
PSR-2 与 PSR-1(和 PSR-0)一样重要。它的目的是使代码易于阅读和维护。但是,正如他们所说,“细节决定成败。”有很多细节需要记住,如果您的编程习惯与标准定义的不同,那么记住这些细节可能会很困难。值得庆幸的是,如果您同意,有一些工具可以帮助您遵守 PSR-0、PSR-1 和 PSR-2。也许最好的工具是 Sublime Text 插件 PHPCS。
PHPCS 插件是我用过的最有帮助的工具,对于让代码成型。它不仅可以让您确保您的代码遵循 PSR 标准,还可以使用 PHP 的 linter 检查语法错误。这非常节省时间;在浏览器中测试代码时,您不必再担心语法错误。
通过 Sublime Package Control(称为 Phpcs)安装包,或者使用 Git,使用以下命令安装包:
cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/ git clone git://github.com/benmatselby/sublime-phpcs.git Phpcs
这将安装插件,但您需要一些依赖项才能配置 PHPCS。再次强调,最简单的安装方法是使用 Composer。浏览到您选择的目录并使用以下 JSON 创建 composer.json
文件:
{ "name": "Nettuts PHPCS Demo", "require": { "squizlabs/php_codesniffer": "*", "fabpot/php-cs-fixer": "*", "phpmd/phpmd": "*" } }
这会将三个依赖项安装到当前文件夹中。打开一个终端窗口到您的安装位置并输入 composer install
,它将下载必要的软件包。
现在您可以在 Sublime Text 中配置插件了。导航到“首选项”>“包设置”>“PHP 代码嗅探器”>“设置 - 用户”。
插件需要知道三个依赖项所在的位置,以及我们希望代码遵守的标准:
{ "phpcs_additional_args": { "--standard": "PSR2", "-n": "" }, "phpcs_executable_path": "DEPENDENCY_PATH/vendor/bin/phpcs", "phpmd_executable_path": "DEPENDENCY_PATH/vendor/bin/phpmd", "php_cs_fixer_executable_path": "DEPENDENCY_PATH/vendor/bin/php-cs-fixer" }
这些设置告知 PHPCS 我们希望遵守 PSR2 标准并提供每个依赖项的路径。不要忘记将 DEPENDENCY_PATH
替换为您的实际路径。
重新启动 Sublime,代码嗅探器将在您保存 PHP 文件时扫描您的代码。
在编辑器中右键单击还将列出几个新选项,例如清除错误标记和尝试修复非标准问题。但是,考虑到本文的目的是让您习惯该标准,我建议手动修复您的代码并避免使用自动修复程序功能。
创建 PSR 标准是为了使代码可以轻松地在项目之间重用,而无需牺牲代码风格的一致性。虽然一开始可能会感到不知所措,但您可以使用本文中的想法和工具来帮助您完成过渡。
最后重申一次:没有人强迫您改变 PHP 编码的方式。它只是一个指南,最初是为了框架互操作性。也就是说,在 Nettuts+,我们认为这是值得遵循的最佳实践。现在你自己拿主意吧!如果您有任何疑问,请在下面听听!
以上是新標題:明顯的PSR!的詳細內容。更多資訊請關注PHP中文網其他相關文章!