编码样式

现在有太多的编码风格,如 PSR-0、PSR-1、PSR-2、PSR-3 等等。程序员可以按照自己的意愿使用不同的标准,但有必要遵循已在使用的库或框架中使用的标准,以使代码更具可读性。例如,Laravel 使用 PSR-1 和 PSR-4 编码标准,因此如果我们使用 Laravel 开发,就应该遵循这些编码标准。一些 PHP 框架,如 Yii 2 和 Zend Framework 2,遵循 PSR-2 编码标准。不过,这些框架都不拘泥于单一的标准;它们大多根据自己的要求,遵循混合的标准。

重要的一点是,要遵循应用程序所用库中使用的标准。企业也可以为内部目的使用自己的编码标准。这不是对编码的要求,而是对可读性的要求,是为了生成他人能理解的高质量代码。

PHP Framework Interop Group (PHP-FIG) 是一个由其成员定义 PHP 编码标准的组织。有关 PSR 标准的详细信息,请访问其网站 http://www.php-fig.org/

与其讨论具体的编码标准,不如让我们讨论一下 PHP 的编码风格最佳实践:

  • 类名中每个单词的第一个字母必须大写。开头括号应放在类声明之后的一行,结尾括号应放在类结束行之后的一行。下面是一个例子:

    class Foo
    {
        …
        …
        …
    }
  • 类方法和函数名应遵循驼峰式命名约定。起始括号应放在类声明的下一行,结束括号应放在函数定义的末尾一行。方法名称和括号之间不能有空格。此外,第一个参数、开头括号、最后一个参数和结尾括号之间不能有空格。此外,一个参数与该参数末尾的逗号之间不应有空格,但逗号与下一个参数之间应有空格。下面是一个例子:

    public function phpBook($arg1, $arg2, $arg3)
    {
        …
        …
        …
    }
  • 如果有命名空间声明,则其声明后必须有一行空行。如果有使用声明,所有声明都必须放在该命名空间的声明之后。每行必须有一个使用声明,使用块后必须有一个空格。此外,extends 和 implements 关键字必须与类声明在同一行。下面是一个例子

    namespace Packt\Videos;
    
    use Packt\Books;
    use Packt\Presentations;
    
    class PacktClass extends VideosClass implements BaseClass
    {
        …
        …
        …
    }
  • 必须为所有属性声明可见性,且属性必须使用驼峰字体。此外,对于私有或受保护的可见性,属性的前缀不得使用下划线。请看下面的示例:

    class PacktClass
    {
        public $books;
        private $electronicBooks;
        …
        …
        …
    }
  • 如果有抽象关键字,对于类来说,它必须出现在类关键字之前;对于方法来说,final 关键字必须出现在方法可见性之前。另一方面,static 关键字必须在方法可见性之后。请看这个例子:

    abstract class PacktClass
    {
        final public static function favoriteBooks()
        {
            …
            …
            …
        }
    }
  • 所有 PHP 关键字都必须使用小写,包括 true 和 false 关键字。常量必须以大写形式声明和使用。

  • 对于所有控制结构,控制结构关键字后必须有一个空格。如果该控制结构有一个表达式,则在该表达式的括号与后面的代码块之间不能有空格。括号和起始括号后必须有一个空格。起始括号必须与控制结构位于同一行。结束括号必须位于正文结束后的一行。请参考以下代码,以便更好地理解:

    if ($book == "PHP 7") {
        …
        …
        …
    } else {
        …
        …
        …
    }
  • 在循环的情况下,空格必须如下例所示:

for ($h = 0; $h < 10; $h++) {
    …
    …
    …
}

foreach ($books as $key => $value) {
    …
    …
    …
}

while ($book) {
    …
    …
    …
}

为了本书的目的,我没有遵循开头支撑与控制结构声明在同一行的规则,而是始终将其用在声明的下一行。我不觉得这样更清楚;这是个人的选择,任何人都可以遵循这里提到的标准。

遵循标准是件好事,因为它们能让代码更易读、更专业。但是,千万不要试图发明自己的新标准,而要始终遵循那些已经发明并被社区遵循的标准。